MySQL常见的优化手段分为下面几个方面：html
SQL优化、设计优化，硬件优化等，其中每一个大的方向中又包含多个小的优化点git
下面咱们具体来看看github
文章首发在公众号（月伴飞鱼），以后同步到掘金和我的网站：xiaoflyfish.cn/算法
以为有收获，但愿帮忙点赞，转发下哈，谢谢，谢谢sql
SQL优化
此优化方案指的是经过优化 SQL 语句以及索引来提升 MySQL 数据库的运行效率，具体内容以下：数据库
分页优化
例如：缓存
select * from table where type = 2 and level = 9 order by id asc limit 190289,10; 复制代码
优化方案：服务器
-
延迟关联网络
先经过where条件提取出主键，在将该表与原数据表关联，经过主键id提取数据行，而不是经过原来的二级索引提取数据行oop
例如：
select a.* from table a, (select id from table where type = 2 and level = 9 order by id asc limit 190289,10 ) b where a.id = b.id 复制代码
-
书签方式
书签方式说白了就是找到limit第一个参数对应的主键值，再根据这个主键值再去过滤并limit
例如：
select * from table where id > (select * from table where type = 2 and level = 9 order by id asc limit 190289, 1) limit 10; 复制代码
索引优化
正确使用索引
假如咱们没有添加索引，那么在查询时就会触发全表扫描，所以查询的数据就会不少，而且查询效率会很低，为了提升查询的性能，咱们就须要给最常使用的查询字段上，添加相应的索引，这样才能提升查询的性能
创建覆盖索引
InnoDB使用辅助索引查询数据时会回表，可是若是索引的叶节点中已经包含要查询的字段，那它没有必要再回表查询了，这就叫覆盖索引
例如对于以下查询：
select name from test where city='上海' 复制代码
咱们将被查询的字段创建到联合索引中，这样查询结果就能够直接从索引中获取
alter table test add index idx_city_name (city, name); 复制代码
在 MySQL 5.0 以前的版本尽可能避免使用or查询
在 MySQL 5.0 以前的版本要尽可能避免使用 or 查询，可使用 union 或者子查询来替代，由于早期的 MySQL 版本使用 or 查询可能会致使索引失效，在 MySQL 5.0 以后的版本中引入了索引合并
索引合并简单来讲就是把多条件查询，好比or或and查询对多个索引分别进行条件扫描，而后将它们各自的结果进行合并，所以就不会致使索引失效的问题了
若是从Explain执行计划的type列的值是index_merge能够看出MySQL使用索引合并的方式来执行对表的查询
避免在 where 查询条件中使用 != 或者 <> 操做符
SQL中，不等于操做符会致使查询引擎放弃索引索引，引发全表扫描，即便比较的字段上有索引
解决方法：经过把不等于操做符改为or，可使用索引，避免全表扫描
例如，把column<>’aaa’，改为column>’aaa’ or column<’aaa’ ，就可使用索引了
适当使用前缀索引
MySQL 是支持前缀索引的，也就是说咱们能够定义字符串的一部分来做为索引
咱们知道索引越长占用的磁盘空间就越大，那么在相同数据页中能放下的索引值也就越少，这就意味着搜索索引须要的查询时间也就越长，进而查询的效率就会下降，因此咱们能够适当的选择使用前缀索引，以减小空间的占用和提升查询效率
好比，邮箱的后缀都是固定的“@xxx.com”，那么相似这种后面几位为固定值的字段就很是适合定义为前缀索引
alter table test add index index2(email(6)); 复制代码
使用前缀索引，定义好长度，就能够作到既节省空间，又不用额外增长太多的查询成本
须要注意的是，前缀索引也存在缺点，MySQL没法利用前缀索引作order by和group by 操做，也没法做为覆盖索引
查询具体的字段而非所有字段
要尽可能避免使用 select *，而是查询须要的字段，这样能够提高速度，以及减小网络传输的带宽压力
优化子查询
尽可能使用 Join 语句来替代子查询，由于子查询是嵌套查询，而嵌套查询会新建立一张临时表，而临时表的建立与销毁会占用必定的系统资源以及花费必定的时间，同时对于返回结果集比较大的子查询，其对查询性能的影响更大
小表驱动大表
咱们要尽可能使用小表驱动大表的方式进行查询，也就是若是 B 表的数据小于 A 表的数据，那执行的顺序就是先查 B 表再查 A 表，具体查询语句以下：
select name from A where id in (select id from B); 复制代码
不要在列上进行运算操做
不要在列字段上进行算术运算或其余表达式运算，不然可能会致使查询引擎没法正确使用索引，从而影响了查询的效率
select * from test where id + 1 = 50; select * from test where month(updateTime) = 7; 复制代码
一个很容易踩的坑：隐式类型转换：
select * from test where skuId=123456 复制代码
skuId这个字段上有索引，可是explain的结果却显示这条语句会全表扫描
缘由在于skuId的字符类型是varchar(32)，比较值倒是整型，故须要作类型转换
适当增长冗余字段
增长冗余字段能够减小大量的连表查询，由于多张表的连表查询性能很低，全部能够适当的增长冗余字段，以减小多张表的关联查询，这是以空间换时间的优化策略
正确使用联合索引
使用了 B+ 树的 MySQL 数据库引擎，好比 InnoDB 引擎，在每次查询复合字段时是从左往右匹配数据的，所以在建立联合索引的时候须要注意索引建立的顺序
例如，咱们建立了一个联合索引是 idx(name,age,sex)，那么当咱们使用，姓名+年龄+性别、姓名+年龄、姓名等这种最左前缀查询条件时，就会触发联合索引进行查询；然而若是非最左匹配的查询条件，例如，性别+姓名这种查询条件就不会触发联合索引
Join优化
MySQL的join语句链接表使用的是nested-loop join算法，这个过程相似于嵌套循环，简单来讲，就是遍历驱动表（外层表），每读出一行数据，取出链接字段到被驱动表（内层表）里查找知足条件的行，组成结果行
要提高join语句的性能，就要尽量减小嵌套循环的循环次数
一个显著优化方式是对被驱动表的join字段创建索引，利用索引能快速匹配到对应的行，避免与内层表每一行记录作比较，极大地减小总循环次数。另外一个优化点，就是链接时用小结果集驱动大结果集，在索引优化的基础上能进一步减小嵌套循环的次数
若是难以判断哪一个是大表，哪一个是小表，能够用inner join链接，MySQL会自动选择小表去驱动大表
避免使用JOIN关联太多的表
对于 MySQL 来讲，是存在关联缓存的，缓存的大小能够由join_buffer_size参数进行设置
在 MySQL 中，对于同一个 SQL 多关联（join）一个表，就会多分配一个关联缓存，若是在一个 SQL 中关联的表越多，所占用的内存也就越大
若是程序中大量的使用了多表关联的操做，同时join_buffer_size设置的也不合理的状况下，就容易形成服务器内存溢出的状况，就会影响到服务器数据库性能的稳定性
排序优化
利用索引扫描作排序
MySQL有两种方式生成有序结果：其一是对结果集进行排序的操做，其二是按照索引顺序扫描得出的结果天然是有序的
可是若是索引不能覆盖查询所需列，就不得不每扫描一条记录回表查询一次，这个读操做是随机IO，一般会比顺序全表扫描还慢
所以，在设计索引时，尽量使用同一个索引既知足排序又用于查找行
例如：
--创建索引（date,staff_id,customer_id） select staff_id, customer_id from test where date = '2010-01-01' order by staff_id,customer_id; 复制代码
只有当索引的列顺序和ORDER BY子句的顺序彻底一致，而且全部列的排序方向都同样时，才可以使用索引来对结果作排序
UNION优化
MySQL处理union的策略是先建立临时表，而后将各个查询结果填充到临时表中最后再来作查询，不少优化策略在union查询中都会失效，由于它没法利用索引
最好手工将where、limit等子句下推到union的各个子查询中，以便优化器能够充分利用这些条件进行优化
此外，除非确实须要服务器去重，必定要使用union all，若是不加all关键字，MySQL会给临时表加上distinct选项，这会致使对整个临时表作惟一性检查，代价很高
慢查询日志
出现慢查询一般的排查手段是先使用慢查询日志功能，查询出比较慢的 SQL 语句，而后再经过 Explain 来查询 SQL 语句的执行计划，最后分析并定位出问题的根源，再进行处理
慢查询日志指的是在 MySQL 中能够经过配置来开启慢查询日志的记录功能，超过long_query_time值的 SQL 将会被记录在日志中
咱们能够经过设置“slow_query_log=1”来开启慢查询
须要注意的是，在开启慢日志功能以后，会对 MySQL 的性能形成必定的影响，所以在生产环境中要慎用此功能
设计优化
尽可能避免使用NULL
NULL在MySQL中很差处理，存储须要额外空间，运算也须要特殊的运算符，含有NULL的列很难进行查询优化
应当指定列为not null，用0、空串或其余特殊的值代替空值，好比定义为int not null default 0
最小数据长度
越小的数据类型长度一般在磁盘、内存和CPU缓存中都须要更少的空间，处理起来更快
使用最简单数据类型
简单的数据类型操做代价更低，好比：能使用 int 类型就不要使用 varchar 类型，由于 int 类型比 varchar 类型的查询效率更高
尽可能少定义 text 类型
text 类型的查询效率很低，若是必需要使用 text 定义字段，能够把此字段分离成子表，须要查询此字段时使用联合查询，这样能够提升主表的查询效率
适当分表、分库策略
分表是指当一张表中的字段更多时，能够尝试将一张大表拆分为多张子表，把使用比较高频的主信息放入主表中，其余的放入子表，这样咱们大部分查询只须要查询字段更少的主表就能够完成了，从而有效的提升了查询的效率
分库是指将一个数据库分为多个数据库。好比咱们把一个数据库拆分为了多个数据库，一个主数据库用于写入和修改数据，其余的用于同步主数据并提供给客户端查询，这样就把一个库的读和写的压力，分摊给了多个库，从而提升了数据库总体的运行效率
常见类型选择
整数类型宽度设置
MySQL能够为整数类型指定宽度，例如int(11)，实际上并无意义，它并不会限制值的范围，对于存储和计算来讲，int(1)和int(20)是相同的
VARCHAR和CHAR类型
char类型是定长的，而varchar存储可变字符串，比定长更省空间，可是varchar须要额外1或2个字节记录字符串长度，更新时也容易产生碎片
须要结合使用场景来选择：若是字符串列最大长度比平均长度大不少，或者列的更新不多，选择varchar较合适；若是要存很短的字符串，或者字符串值长度都相同，好比MD5值，或者列数据常常变动，选择使用char类型
DATETIME和TIMESTAMP类型
datetime的范围更大，能表示从1001到9999年，timestamp只能表示从1970年到2038年。datetime与时区无关，timestamp显示值依赖于时区。在大多数场景下，这两种类型都能良好地工做，可是建议使用timestamp，由于datetime占用8个字节，timestamp只占用了4个字节，timestamp空间效率更高
BLOB和TEXT类型
blob和text都是为存储很大数据而设计的字符串数据类型，分别采用二进制和字符方式存储
在实际使用中，要慎用这两种类型，它们的查询效率很低，若是字段必需要使用这两种类型，能够把此字段分离成子表，须要查询此字段时使用联合查询，这样能够提升主表的查询效率
范式化
当数据较好范式化时，修改的数据更少，并且范式化的表一般要小，能够有更多的数据缓存在内存中，因此执行操做会更快
缺点则是查询时须要更多的关联
第一范式：字段不可分割，数据库默认支持
第二范式：消除对主键的部分依赖，能够在表中加上一个与业务逻辑无关的字段做为主键，好比用自增id
第三范式：消除对主键的传递依赖，能够将表拆分，减小数据冗余
硬件优化
MySQL 对硬件的要求主要体如今三个方面：磁盘、网络和内存
磁盘
磁盘应该尽可能使用有高性能读写能力的磁盘，好比固态硬盘，这样就能够减小 I/O 运行的时间，从而提升了 MySQL 总体的运行效率
磁盘也能够尽可能使用多个小磁盘而不是一个大磁盘，由于磁盘的转速是固定的，有多个小磁盘就至关于拥有多个并行运行的磁盘同样
网络
保证网络带宽的通畅（低延迟）以及够大的网络带宽是 MySQL 正常运行的基本条件，若是条件容许的话也能够设置多个网卡，以提升网络高峰期 MySQL 服务器的运行效率
内存
MySQL 服务器的内存越大，那么存储和缓存的信息也就越多，而内存的性能是很是高的，从而提升了整个 MySQL 的运行效率
若是以上文章对您有帮助，请给咱们的开源项目点点star： http://github.crmeb.net/u/defu 不胜感激！
来自 “开源世界 ” ，连接：https://ym.baisou.ltd/post/726.html，如需转载，请注明出处，不然将追究法律责任。