sql优化

SQL Server 存储过程

南笙酒味 提交于 2020-01-10 18:15:00
Transact-SQL中的存储过程,非常类似于Java语言中的方法,它可以重复调用。当存储过程执行一次后,可以将语句缓存中,这样下次执行的时候直接使用缓存中的语句。这样就可以提高存储过程的性能。 Ø 存储过程的概念 存储过程Procedure是一组为了完成特定功能的SQL语句集合,经编译后存储在数据库中,用户通过指定存储过程的名称并给出参数来执行。 存储过程中可以包含逻辑控制语句和数据操纵语句,它可以接受参数、输出参数、返回单个或多个结果集以及返回值。 由于存储过程在创建时即在数据库服务器上进行了编译并存储在数据库中,所以存储过程运行要比单个的SQL语句块要快。同时由于在调用时只需用提供存储过程名和必要的参数信息,所以在一定程度上也可以减少网络流量、简单网络负担。 1、 存储过程的优点 A、 存储过程允许标准组件式编程 存储过程创建后可以在程序中被多次调用执行,而不必重新编写该存储过程的SQL语句。而且数据库专业人员可以随时对存储过程进行修改,但对应用程序源代码却毫无影响,从而极大的提高了程序的可移植性。 B、 存储过程能够实现较快的执行速度 如果某一操作包含大量的T-SQL语句代码,分别被多次执行,那么存储过程要比批处理的执行速度快得多。因为存储过程是预编译的,在首次运行一个存储过程时,查询优化器对其进行分析、优化,并给出最终被存在系统表中的存储计划。而批处理的T

MySQL的InnoDB索引原理详解

自闭症网瘾萝莉.ら 提交于 2020-01-10 16:19:36
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 摘要 本篇介绍下Mysql的InnoDB索引相关知识,从各种树到索引原理到存储的细节。 InnoDB是Mysql的默认存储引擎(Mysql5.5.5之前是MyISAM, 文档 )。本着高效学习的目的,本篇以介绍InnoDB为主,少量涉及MyISAM作为对比。 这篇文章是我在学习过程中总结完成的,内容主要来自书本和博客(参考文献会给出),过程中加入了一些自己的理解,描述不准确的地方烦请指出。 1 各种树形结构 本来不打算从二叉搜索树开始,因为网上已经有太多相关文章,但是考虑到清晰的图示对理解问题有很大帮助,也为了保证文章完整性,最后还是加上了这部分。 先看看几种树形结构: 1 搜索二叉树:每个节点有两个子节点,数据量的增大必然导致高度的快速增加,显然这个不适合作为大量数据存储的基础结构。 2 B树:一棵m阶B树是一棵平衡的m路搜索树。最重要的性质是每个非根节点所包含的关键字个数 j 满足:┌m/2┐ – 1 <= j <= m – 1;一个节点的子节点数量会比关键字个数多1,这样关键字就变成了子节点的分割标志。一般会在图示中把关键字画到子节点中间,非常形象,也容易和后面的 B+树区分。由于数据同时存在于叶子节点和非叶子结点中,无法简单完成按顺序遍历B树中的关键字,必须用中序遍历的方法。 3 B+树

mysql 索引优化法则

微笑、不失礼 提交于 2020-01-10 15:26:31
建表语句 CREATE TABLE staffs( id INT PRIMARY KEY AUTO_INCREMENT, NAME VARCHAR (24) NOT NULL DEFAULT '' COMMENT '姓名', age INT NOT NULL DEFAULT 0 COMMENT '年龄', pos VARCHAR (20) NOT NULL DEFAULT 0 COMMENT '职位', add_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间' ) CHARSET utf8 COMMENT '员工记录表'; INSERT INTO staffs(NAME, age, pos, add_time) VALUES('ronnie', 22, 'manager', NOW()); INSERT INTO staffs(NAME, age, pos, add_time) VALUES('John', 23, 'devloper', NOW()); INSERT INTO staffs(NAME, age, pos, add_time) VALUES('2181', 27, 'devloper', NOW()); -- 建复合索引 alter table staffs add index idx

基于oracle的sql优化

↘锁芯ラ 提交于 2020-01-10 13:53:45
基于oracle的sql优化 基于oracle的sql优化 一.编写初衷描述 在应有系统开发初期,由于数据库数据较少,对于sql语句各种写法的编写体现不出sql的性能优劣,随着数据的不断增加,出现海量数据,劣质sql与优质sql在执行效率甚至存在百倍差距,可见sql优化的重要性 二.Sql语句性能优化 2.1 认识Oracle的执行过程 2.2 Oracle优化法则—漏斗法则 2.3 Oracle 执行计划 2.3.1 什么是Oracle执行计划 执行计划是一条查询语句在Oracle中执行过程或者访问路径的描述. 2.3.2 查看Oracle执行计划 1.执行计划常用的列字段解释 基数:返回的结果集行数 字节:执行该步骤后返回的字节数 耗费(cust),CPU耗费:Oracle估计的该步骤的执行成本,用于说明SQL执行的代价,理论上越小越好. 2.3.3 看懂Oracle执行计划 2.3.3.1执行顺序 根据缩进来判断,缩进最多的最先执行(缩进相同时,最上面的最先执行) 2.4 表的访问方式 TABLE ACCESS FULL ( 全表扫描 ) TABLE ACCESS BY ROWID ( 通过rowid的表存取 ) TABLE ACCESS BY INDEX SCAN ( 索引扫描 ) 2.4.1 ABLE ACCESS FULL(全表扫描) Oracle会读取表中的所有行

深入Mysql

血红的双手。 提交于 2020-01-10 13:33:51
深入Mysql 在学习sql,使用sql后,有时候不理解sql代码为什么这样写?如果能了解sql代码的运行,就能够深入理解了。 8.2.1.7 Nested-Loop Join Algorithms 嵌套循环连接算法 https://dev.mysql.com/doc/refman/8.0/en/nested-loop-joins.html Nested-Loop Join Algorithm Block Nested-Loop Join Algorithm 简单的NLJ算法 读取行,在一个循环内,从第一个表每次读一行x,并传递x到内部嵌套的循环(被join的下一个表格的处理)。 这个过程被重复多次,每次处理一个被join的表格。 ⚠️本质就是嵌套循环,一个表一个循环。层层嵌套。 例子:3个表关联。所以嵌套3层。 Table Join Type t1 range t2 ref t3 ALL for each row in t1 matching range { for each row in t2 matching reference key { for each row in t3 { if row satisfies join conditions, send to client } } } 问题? Join Type类型不理解 https://dev.mysql.com

Mysql 性能优化Explain详解

旧城冷巷雨未停 提交于 2020-01-10 13:25:06
explain 功能 我们在日常使用中,使用慢查询找到执行时间比较久的查询,然后使用SHOW STATUS、SHOW PROFILE、和explain做单条语句的分析。 使用explain关键字可以模拟优化器执行sql查询语句,从而知道Mysql是如何处理你的sql语句的。分析你的查询语句或者表结构的性能瓶颈。 具体可以分析哪些 表的读取顺序 数据读取操作的操作类型 哪些索引可以使用 哪些索引被实际使用 表之间的引用 每张表有多少行被优化器查询 使用语法 explain sql语句 得到了什么结果 expain出来的信息有10列,分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra 字段概要解释: id:选择标识符 select_type:表示查询的类型。 table:输出结果集的表 partitions:匹配的分区 type:表示表的连接类型 possible_keys:表示查询时,可能使用的索引 key:表示实际使用的索引 key_len:索引字段的长度 ref:列与索引的比较 rows:扫描出的行数(估算的行数) filtered:按表条件过滤的行百分比 Extra:执行情况的描述和说明 字段详细解释 一、 id SQL执行查询的顺序的标识 1. id相同时,执行顺序由上至下 2.

MySQL常用规范

▼魔方 西西 提交于 2020-01-10 13:18:11
一. 建表规范 1.使用InnoDB引擎 无特殊情况必须使用InnoDB引擎(5.5版本后默认引擎) InnoDB支持事务、行级锁、MVCC,并发性能更好,CPU及内存缓存页优化使得资源利用率更好。 2.规范表、字段的命名 表名、字段名,小写下划线风格,尽量做到见名知意。 3.规范索引命名 主键索引名为pk_表名_字段名,唯一索引名为uk_表名_字段名,普通索引为idx_表名_字段名。 4.字段NOT NULL的好处 NULL的列使索引、索引统计、值得比较都更加复杂; NULL类型MySQL内部需要特殊处理,增加处理记录的复杂性,NULL的列需要额外的空间来标识; 对NULL的处理是能采用IS NULL或IS NOT NULL:WHERE name != '张三'; 的查询结果不会包含name为NULL的记录。 5.char与varchar 如果存储的字符串长度固定,则应该使用char定长字符串类型,存取效率较高; 如果字符串长度不固定,则应该使用varchar变长字符串类型,它会根据字符串实际长度分配空间,节约资源。如果字符串长度超过5000,应该定义字段类型为text等大文本,并独立一张表,用主键关联,避免影响其他字段的索引效率。 二. 索引规范 1.善于使用唯一索引 业务上具有唯一特性的字段,即使是多个字段组成,也必须建成唯一索引,唯一索引可以显著提高查询效率

Windows + Linux Mysql慢查询日志开启的方法

為{幸葍}努か 提交于 2020-01-10 10:34:16
打开MySQL慢查询 MySQL慢查询记录日志对于跟踪PHP+MySQL 体系下的MySQL负载调优问题很有用处,比如安装了很多Discuz!插件的用户,这样可以大概排查出那些插件有代码问题。其实启用MySQL的慢查询 日志很简单,只需要在MySQL的配置文件里添加log-slow-queries和 long_query_time两个参数即可。 今天有个朋友问我,就顺带记录上来。更多的MySQL 优化信息可以查看这里:http://www.ccvita.com/category/mysql Windows下开启MySQL慢查询 MySQL在Windows系统中的配置文件一般是是my.ini找到[mysqld]下面加上 log-slow-queries = F:\MySQL\log\mysqlslowquery.log long_query_time = 2 Linux下启用MySQL慢查询 MySQL在Windows系统中的配置文件一般是是my.cnf找到[mysqld]下面加上 log-slow-queries=/data/mysqldata/slowquery.log long_query_time=2 注意 log-slow-queries = F:\MySQL\log\mysqlslowquery.log为慢查询日志存放的位置,一般这个目录要有MySQL的运行帐号的可写权限

容易理解的mysql分区

走远了吗. 提交于 2020-01-10 10:18:00
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> InnoDB逻辑存储结构   首先要先介绍一下InnoDB逻辑存储结构和区的概念, 它的所有数据都被逻辑地存放在表空间,表空间又由段,区,页组成。 段 段就是上图的segment区域,常见的段有数据段、索引段、回滚段等,在InnoDB存储引擎中,对段的管理都是由引擎自身所完成的。 区   区就是上图的extent区域, 区是由连续的页组成的空间,无论页的大小怎么变,区的大小默认总是为1MB。 为了保证区中的页的连续性,InnoDB存储引擎一次从磁盘申请4-5个区,InnoDB页的大小默认为16kb,即一个区一共有64(1MB/16kb=16)个连续的页。每 个段开始,先用32页(page)大小的碎片页来存放数据,在使用完这些页之后才是64个连续页的申请。这样做的目的是,对于一些小表或者是undo类的段,可以开始申请较小的空间,节约磁盘开销。 页   页就是上图的page区域,也可以叫块。 页是InnoDB磁盘管理的最小单位。 默认大小为16KB,可以通过参数innodb_page_size来设置。常见的页类型有:数据页,undo页,系统页,事务数据页,插入缓冲位图页,插入缓冲空闲列表页,未压缩的二进制大对象页,压缩的二进制大对象页等。 分区概述 分区    这里讲的分区,此“区”非彼“区”

MySQL 对于千万级的大表要怎么优化?

試著忘記壹切 提交于 2020-01-10 07:27:31
首先采用Mysql存储千亿级的数据,确实是一项非常大的挑战。Mysql单表确实可以存储10亿级的数据,只是这个时候性能非常差,项目中大量的实验证明,Mysql单表容量在500万左右,性能处于最佳状态。 针对大表的优化,主要是通过数据库分库分表来解决,目前比较普遍的方案有三个:分区,分库分表,NoSql/NewSql。实际项目中,这三种方案是结合的,目前绝大部分系统的核心数据都是以RDBMS存储为主,NoSql/NewSql存储为辅。 分区 首先来了解一下分区方案。 分区表是由多个相关的底层表实现的。这些底层表也是由句柄对象表示,所以我们也可以直接访问各个分区,存储引擎管理分区的各个底层表和管理普通表一样(所有的底层表都必须使用相同的存储引擎),分区表的索引只是在各个底层表上各自加上一个相同的索引。这个方案对用户屏蔽了sharding的细节,即使查询条件没有sharding column,它也能正常工作(只是这时候性能一般)。 不过它的缺点很明显:很多的资源都受到单机的限制,例如连接数,网络吞吐等。如何进行分区,在实际应用中是一个非常关键的要素之一。 下面开始举例:以客户信息为例,客户数据量5000万加,项目背景要求保存客户的银行卡绑定关系,客户的证件绑定关系,以及客户绑定的业务信息。 此业务背景下,该如何设计数据库呢。项目一期的时候,我们建立了一张客户业务绑定关系表