sql常用优化

mysql服务器优化

在sql优化前，了解mysql的基础参数，然后有针对性的调优是很有必要的：

max_connections

mysql的最大连接数， 我们偶尔会遇到Too mant connetcions错误，这说明当前并行连接超过设置值

max_connections值的大小取决于：

• 给定平台上线程库的质量
• 可用的RAM量
• 每个连接使用的RAM
• 每个连接的工作负载
• 所需的响应时间
• 可用文件描述符的数量
  增大该 max_connections值会增加mysqld所需的文件描述符的数量 。如果所需数目的描述符不可用，则服务器将减少max_connections的值。
  max_connections过大会造成mysql初始化内存变大，因为max_connections会为每个连接提供RAM，过大的max_connections就会造成大量的物理机内存开销，让服务器宕机也是有可能的事。因此合理分配max_connections也是项目非常重要的一环。
  合理分配方式：
  max_connections产生内存 = 最大连接数* 每个连接使用的RAM
  在服务器可用内存，能够负担的情况下:
  show status like ‘max_used_connections’响应的连接数
  查看max_used_connections，
  max_used_connections / max_connections * 100% （理想值≈ 85%）
  如果max_used_connections跟max_connections相同 那么就是max_connections设置过低或者超过服务器负载上限了，低于10%则设置过大。

back_log

MySQL可以拥有的未完成连接请求数。当主要的MySQL线程在很短的时间内收到很多连接请求超过max_connections，这就会起作用。该 back_log值指示在MySQL暂时停止回答新请求之前的短时间内可以堆叠多少个请求。仅当您期望在短时间内有大量连接时，才需要增加此数量。
默认值基于以下公式，上限为900：
50 + (max_connections / 5)

innodb_buffer_pool_size

配置InnoDB缓冲池大小，当增加或减少时 innodb_buffer_pool_size，将按块执行操作。块大小由innodb_buffer_pool_chunk_size 配置选项定义 ，其默认值为 128M。缓冲池大小必须始终等于innodb_buffer_pool_chunk_size的倍数，如果不为倍数，缓冲池大小将自动调整为等于innodb_buffer_pool_chunk_size的倍数。

• 判断缓冲池是否过大
  show engine innodb status\G
  
  Free buffers :表示有多少空闲buffer。如果 此值长时间都较高，则可以考虑减小InnoDB缓冲池大小。

• 配置的innodb_buffer_pool_size是否合适？
  show status like ‘innodb_buffer_pool_read%’;
  

Performance = innodb_buffer_pool_reads / innodb_buffer_pool_read_requests * 100

innodb_buffer_pool_reads：表示InnoDB缓冲池无法满足的请求数。需要从磁盘中读取。

innodb_buffer_pool_read_requests：表示从内存中读取逻辑的请求数。

0.0002797533222203554意味着InnoDB可以满足缓冲池本身的大部分请求。从磁盘完成读取的百分比非常小。因此无需增加innodb_buffer_pool_size值。

thread_cache_size

服务器应缓存多少线程以供重用。当客户端断开连接时，如果那里的thread_cache_size线程少于该线程，则将客户端的线程放入缓存中 。通过尽可能地重用从缓存中获取的线程来满足线程请求，并且仅当缓存为空时才创建新线程。如果您有很多新连接，则可以增加此变量以提高性能。通常，如果您具有良好的线程实现，则这不会显着提高性能。但是，如果您的服务器每秒看到数百个连接，则通常应设置 thread_cache_size足够高，以便大多数新连接使用缓存的线程。
默认值基于以下公式，上限为100：
8 + (max_connections / 100)

mysql数据库结构优化

优化数值数据

1. 对于可以表示为字符串或数字的唯一ID或其他值，与字符串列相比，首选数字列。由于大数值可以比相应字符串存储在更少的字节中，因此传输速度更快，并且占用更少的内存来进行比较。

2. 如果您使用的是数字数据，则在许多情况下（通过实时连接）从数据库访问信息的访问要比访问文本文件更快。数据库中的信息很可能以比文本文件更紧凑的格式存储，因此访问它涉及的磁盘访问较少。

优化字段类型

数据的检索效率： char > varchar > text
1、经常变化的字段用varchar；
2、知道固定长度的用char；
3、超过255字节的只能用varchar或者text；
4、能用varchar的地方不用text；
5、能够用数字类型的字段尽量选择数字类型而不用字符串类型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了；
6、同一张表出现多个大字段，能合并时尽量合并，不能合并时考虑分表

业务逻辑优化

分表

随着时间和业务的发展，同一个表中的数据量不可避免的越来越大，相应地，数据操作，增删改查的开销也会越来越大。因此我们可以按照业务逻辑的划分，将一个表拆分成多个表。例如商品表，我们可以根据商品类型拆分成：普通商品表、积分商品表、特价山商品表等等。

读写分离

在多台服务器上部署mysql，将其中一个设置为主数据库，负责写入操作，其他数据库设置为从数据库，负责读取操作。开启slave实现数据库同步，这样可以极大的减轻数据库的压力。

sql语句优化

开启慢查询

要实现对sql语句性能实时的监控，首先要开启慢查询。
查看慢查询是否开启
show variables like ‘slow_query%’;

查看参数设置
show variables like ‘long_query_time’;

开启慢查询
set global slow_query_log=‘ON’;

设置慢查询时间：
set global long_query_time=1;
超过一秒就记录下来

检查explain

当我们记录下来这些查询比较慢的sql，就可以有针对性的去优化了。首先执行sql，点击解析按钮，查看type列。
当语句的type为all时说明是全表扫描，这个时候我们就可以有针对性的对sql进行优化、例如加索引、避免使用让索引失效的从而引发全表扫描的命令

参考文档：
1.https://www.cnblogs.com/wanbin/p/9530833.html