慢查询日志的使用
查询慢日志是否开启：show variables like ‘slow_query_log’; 或 show variables like ‘slow_query%’;
开启慢日志：set global slow_query_log=1;
查询慢日志临界时间：show variables like ‘long_query_time’; 或 show variables like ‘long_query%’;
选择合适的存储引擎
如果不考虑事务的表，只是读写，如日志表，可以考虑选择MYISAM存储引擎。如果不知道选择怎样的存储引擎，InnoDB都是不错的选择。
优化索引
索引可以让服务器快速的定位到表的指定位置，但是这并不是索引的唯一作用 。
我们最常用的索引是B数索引，他是按照顺序存储数据，索引可以用来order by和group by操作，又因为索引中存储了实际的列值，索引某些查询只使用索引就能够完成全部查询。
总的来说，索引有三个优点：1.减少了服务器需要扫描的数量。2.帮助服务器免排序和临时表。3.可以将随机I/O变为顺序I/O 。
优化：
- 索引不能是表达式的一部分，也不能是函数的参数。例如：select a from table where a + 1 = 5;
- 当索引的字符列很长时，会让索引变得大且慢，可以索引开始的部分字符，这样可以大大节约索引空间，从而提高索引效率，但是会降低索引的选择性，所以我们选择开始字符长度的基数应接近完整列的基数。这里说的基数是根据全部值查出来的数据个数与开始字符长度查出来的个数。
- 避免为每个列创建独立的索引。为每个列创建独立的索引并不能提高MYSQL的查询性能，以为索引也需要维护，过多的索引维护会带来过多的消耗，从而影响性能。
- 建议创建合适的组合索引，索引的顺序至关重要。当不需要考虑排序和分组时，可将选择性最高的列放到索引的最前列。
- 在设置主键时，应尽量设置为自增，在数据插入时避免主键被更新需要移动位置，有可能导致页分裂的问题。
- 在使用InnoDB存储引擎时，尽量能够使用覆盖索引，避免回表操作。
- 避免创建重复索引，因为MYSQL需要单独维护重复索引，并且优化器在优化查询的时候也需要逐个的进行考虑，这样会影响性能。
- 避免冗余索引和未使用的索引。索引的维护也消耗性能。
数据类型优化
MYSQL支持的数据类型非常多，选择正确的数据类型对于获得高性能至关重要。在选择合适的数据类型时，有几个原则可有助于做出选择。
更小的通常更好。一般情况下应尽量使用可以正确存储数据的最小数据类型，更小的数据类型通常更快，因为占用更少的磁盘、内存和CPU缓存，并且处理时需要的CPU周期也更少。
简单就好。简单数据类型的操作通常需要更少的CPU周期。
尽量避免NULL。如果查询中包含可为NULL的列，对MYSQL来说更难优化，因为可为NULL的列使索引、索引统计和值比较都更复杂。可为NULL的列会使用更多的存储空间，在MYSQL里也需要特殊处理。当可为NULL的列被索引时，每个索引记录需要一个额外的字节。在MYISAM存储引擎里甚至还可能导致固定大小的索引变成可变大小的索引。在设计索引时，就应该尽量避免设计成可为NULL的列。
（每个数据类型的选择先不讲，可自查）
查询优化 (SQL优化)
- 分解关联查询。将一个多表关联查询分解成对每一个表进行一次单表查询，然后将结果在应用程序中进行关联。这样做的好处有：1.让缓存的效率更高。如果多表关联查询，一个表发生了变化，缓存就会失效。2.可以减少锁竞争。3. 更容易对数据库进行拆分，更容易做到高性能和可扩展。4.查询本身效率也有可能得到提升。5.可以减少冗余记录的查询。
- Limit 分页优化。如果数据量很大的表，偏移量很大时候，查询性能会低，可以考虑索引覆盖的方式，例如先返回数据的主键，再根据主键查询返回所需的数据。
读写分离
分库分表
文章推荐：
若有收获，就点个赞吧
0 人点赞
