MySql中如何使用explain查询SQL的执行计划

哎，这个东西确实很重要，但是我每次用的时候都觉得有点绕。
上次我大概花了半个月的时间去理解和讲解，遇到了很多坑。

先说一下我踩过的坑。
2 02 3 年，我在上海一家购物中心做技术支持。
客户数据库中的查询极其缓慢且卡住。
我一看日志，哦，解释结果是ALL，表分析了几十万行。
我当时很着急，赶紧查了资料，发现一切都是最坏的情况。
但知道这就是一切有什么意义呢？您需要查看哪个表和列导致了问题。
例如，在我的示例中，解释 select from payment;结果中，类型为ALL，表为 payment，行数为 1 6 ,08 6 行。
这提醒我需要快速为支付表添加索引，尤其是查询条件中经常涉及到的字段。

看看这些列，比如id，就是查询的序列号。
select_type 告诉您它是简单查询还是子查询。
类型是最关键的。
ALL是全表扫描，必须修改。
possible_keys 告诉您 MySQL 可以使用哪些索引。
关键是实际索引。
key_len 越短越好。
rows 是要检查的估计行数。
如果这个数字很大，我们就必须想办法。
使用索引（索引扫描）很好，使用临时（临时表）和使用filesort（文件排序）可能是优化的。

但说实话，解释并不是万能的。
2 02 2 年在北京另一家公司的项目中就遇到了这个问题，解释清楚了是引用，索引建正确了，但是结果查询还是慢。
后来发现是系统资源瓶颈，CPU爆了。
在这种情况下，解释是盲目的。
所以你看，它提供了最好的信息，但不是全部真相。

我建议你从类型和线条开始。
如果类型是ALL或者index，那么索引基本上都需要优化。
如果行特别大，例如数十万行，那么您需要找到减少数据量的方法，例如通过添加更精细的索引或使用分区表。
额外列有时很有用。
例如，如果您看到“使用临时”，这会提醒您可能需要重写查询。

无论如何，这取决于你。
解释是基本工具，但必须结合实际情况。
有时候你觉得计划没有什么问题，但实际执行起来还是很慢。
那么你可能需要从硬件、系统配置或者业务逻辑上寻找原因。
我时常思考这个问题。
有时对要解释的行的估计并不准确，尤其是当数据量很大时。
这个数字只能作为参考，并不能完全可靠。

如何查看mysql执行过的语句

注册MySQL来执行SQL很简单。
将行 log=/var/lib/mysql/sql_row.log 添加到 /etc/my.cnf 中的 [mysqld] 部分。
决定你自己的路。
重新启动 MySQL。
查看文件/var/lib/mysql/sql_row.log。
使用 MySQL 重新启动服务重新启动。
或者使用/etc/init.d/mysqld stop/start。

mysql查询sql执行过的历史语句

通用查询日志：记录所有SQL，显示：显示“general_log”等变量； ON：设置全局general_log='ON'；注意：在生产环境中请谨慎使用，因为它会消耗空间并影响性能。

慢查询日志：慢SQL日志，显示：show Variables as 'slow_query_log'；开：设置全局slow_query_log='开'；设置阈值：SET GLOBAL long_query_time=n;注意：影响性能。

二进制日志：记录数据变化，显示：show Variables as 'log_bin'；用法：mysqlbinlog工具。

系统表：PROCESSLIST 和 events_statements_history，需要权限。

实用提醒：请确保打开历史记录并使用工具查看。