本文共 2725 字,大约阅读时间需要 9 分钟。
数据库优化从多个维度进行,针对SQL和系统性能都需要综合考虑。以下是针对SQL优化的详细探讨,结合实际案例说明优化方法和技巧。
判断SQL是否存在问题可以从以下两个方面进行分析:
系统级别的性能问题可能反映在以下方面:
可以通过使用sar
和top
命令查看系统资源使用情况,或者借助Prometheus、Grafana等监控工具,实时监控系统状态。
从SQL本身进行分析,主要关注以下方面:
Type=ALL
且rows
很大,通常意味着查询效率很低。特别需要注意的是,执行计划中的key
列显示ALL
,这表明当前查询可能存在“坏味道”,需要优化。
针对不同数据库的慢查询日志获取方式:
loadrunner
等,用于模拟并抓取慢查询。ptquery
,专门用于分析慢查询。v$sql
、v$session_wait
等,直接关联到慢查询。v$sql
、v$session_wait
等。编写高效的SQL语句需要遵循以下原则:
合理使用索引
使用UNION ALL替代UNION
UNION ALL
省去了排重和排序操作,效率更高。避免SELECT *
SELECT *
,因为优化器需要将其转换为具体字段查询,可能无法走覆盖索引。JOIN字段建议建立索引
避免复杂SQL
避免WHERE 1=1
WHERE
条件时,尽量避免1=1
等固定值,直接写出真实条件更好。避免ORDER BY RAND()
通过实际案例分析,了解如何从系统和SQL两个层面进行优化。
CREATE TABLE `a` ( `id` int AUTO_INCREMENT, `seller_id` bigint DEFAULT NULL, `seller_name` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, `gmt_create` varchar(30) DEFAULT NULL, PRIMARY KEY (`id`));CREATE TABLE `b` ( `id` int AUTO_INCREMENT, `seller_name` varchar(100) DEFAULT NULL, `user_id` varchar(50) DEFAULT NULL, `user_name` varchar(100) DEFAULT NULL, `sales` bigint DEFAULT NULL, `gmt_create` varchar(30) DEFAULT NULL, PRIMARY KEY (`id`));CREATE TABLE `c` ( `id` int AUTO_INCREMENT, `user_id` varchar(50) DEFAULT NULL, `order_id` varchar(100) DEFAULT NULL, `state` bigint DEFAULT NULL, `gmt_create` varchar(30) DEFAULT NULL, PRIMARY KEY (`id`));
SELECT a.seller_id, a.seller_name, b.user_name, c.stateFROM a, b, cWHERE a.seller_name = b.seller_name AND b.user_id = c.user_id AND c.user_id = 17 AND a.gmt_create BETWEEN DATE_ADD(NOW(), INTERVAL –600 MINUTE) AND DATE_ADD(NOW(), INTERVAL 600 MINUTE)ORDER BY a.gmt_create;
数据量分析
原执行时间
原执行计划
EXPLAIN
命令获取执行计划,重点关注key
和rows
的值。优化思路
user_id
字段在b
和c
表中与a
表中的seller_id
类型一致。user_id
和seller_name
字段创建索引。优化步骤
b
和c
表的user_id
字段为int
类型。user_id
字段创建索引。seller_name
字段创建复合索引。优化效果
执行计划分析
EXPLAIN
工具详细分析查询执行计划,找出低效部分。告警信息处理
索引策略
持续优化
通过以上方法,可以显著提升数据库性能,减少慢查询对业务的影响。
转载地址:http://bouyz.baihongyu.com/