数据库优化new

数据库优化维度有四个:

硬件、系统配置、数据库表结构、SQL及索引

 


 

SQL优化方向

1、查看slowlog,分析slowlog,分析出查询慢的语句。

2、按照一定优先级,进行一个一个的排查所有慢语句。

3、分析top sql,进行explain调试,查看语句执行时间。

 

1)慢日志

慢查询日志,是MySQL提供的一种日志记录,用来记录在MySQL中响应时间超过阀值的语句。

具体环境中,运行时间超过long_query_time值的SQL语句,则会被记录到慢查询日志中。

long_query_time的默认值为10,意思是记录运行10秒以上的语句。

默认情况下,MySQL数据库并不启动慢查询日志,需要手动来设置这个参数。

当然,如果不是调优需要的话,一般不建议启动该参数,因为开启慢查询日志会或多或少带来一定的性能影响。

参数

MySQL 慢查询的相关参数解释:

slow_query_log:是否开启慢查询日志,1表示开启,0表示关闭。

log-slow-queries :旧版(5.6以下版本)MySQL数据库慢查询日志存储路径。可以不设置该参数,系统则会默认给一个缺省的文件host_name-slow.log

slow-query-log-file:新版(5.6及以上版本)MySQL数据库慢查询日志存储路径。可以不设置该参数,系统则会默认给一个缺省的文件host_name-slow.log

long_query_time:慢查询阈值,当查询时间多于设定的阈值时,记录日志。

log_queries_not_using_indexes:未使用索引的查询也被记录到慢查询日志中(可选项)。

log_output:日志存储方式。log_output='FILE'表示将日志存入文件,默认值是'FILE'。log_output='TABLE'表示将日志存入数据库。

mysqldumpslow工具

在生产环境中,如果要手工分析日志,查找、分析SQL,显然是个体力活。

MySQL提供了日志分析工具mysqldumpslow

https://blog.csdn.net/qq_40884473/article/details/89455740

 

2)explain

需要重点关注 type、rows、filtered、extra。

type列,连接类型。一个好的SQL语句至少要达到range级别。杜绝出现all级别。

key列,使用到的索引名。如果没有选择索引,值是NULL。可以采取强制索引方式。

key_len列,索引长度。

rows列,扫描行数。该值是个预估值。

extra列,详细说明。注意,常见的不太友好的值,如下:Using filesort,Using temporary。

 

3 )索引优化

1、MySQL支持两种方式的排序filesortindex,Using index是指MySQL扫描索引本身完成排序。index
效率高,filesort效率低。
2、order by满足两种情况会使用Using index。
 1) order by语句使用索引最左前列
 2) 使用where子句与order by子句条件列组合满足索引最左前列。
3、尽量在索引列上完成排序,遵循索引建立(索引创建的顺序)时的最左前缀法则。
4、如果order by的条件不在索引列上,就会产生Using filesort。
5、能用覆盖索引尽量用覆盖索引
6、group by与order by很类似,其实质是先排序后分组,遵照索引创建顺序的最左前缀法则。对于group
by的优化如果不需要排序的可以加上order by null禁止排序。注意,where高于having,能写在where中
的限定条件就不要去having限定了

4)复杂语句优化

分页查询优化

1、根据自增且连续的主键排序的分页查询

显然改写后的 SQL 走了索引,而且扫描的行数大大减少,执行效率更高。
但是,这条改写的SQL 在很多场景并不实用,因为表中可能某些记录被删后,主键空缺,导致结果不一致,
2、根据非主键字段排序的分页查询
发现并没有使用 name 字段的索引(key 字段对应的值为 null),具体原因上节课讲过:扫描整个索引并查找到没索引的行(可能要遍历多个索引树)的成本比扫描全表的成本更高,所以优化器放弃使用索引。
知道不走索引的原因,那么怎么优化呢?
其实关键是让排序时返回的字段尽可能少,所以可以让排序和分页操作先查出主键,然后根据主键查到对应的记录,SQL改写如下
mysql> select * from employees e inner join (select id from employees order by name limit 90000,5) ed on e.id = ed.id;
需要的结果与原 SQL 一致,执行时间减少了一半以上,我们再对比优化前后sql的执行计划:
原 SQL 使用的是 filesort 排序,而优化后的 SQL 使用的是索引排序。
 
 
https://note.youdao.com/ynoteshare/index.html?id=df15aba3aa76c225090d04d0dc776dd9&type=note&_time=1649747037276

 

架构优化方向

高可用架构、高性能架构

1)分布式缓存

热点数据可放redis等缓存

2)分库分表

历史表

3)读写分离

主库,提供数据库写服务;从库,提供数据库读能力;主从之间,通过binlog同步数据

 

  1. 读写分离主要是用于解决 “数据库读性能问题”
  2. 水平切分主要是用于解决“数据库数据量大的问题”
  3. 分布式缓存架构可能比读写分离更适用于高并发、大数据量大场景。

 

 

 

https://www.zhihu.com/question/36431635

 

posted @ 2022-04-12 15:46  Nausicaa0505  阅读(23)  评论(0编辑  收藏  举报