答案：通过开启慢查询日志和Performance Schema，结合pt-query-digest分析与EXPLAIN执行计划优化，可有效监控并解决MySQL的慢查询与热点表问题。
监控MySQL中的慢查询和热点表是保障数据库性能的关键。核心方法是结合日志记录、性能视图分析与索引优化，快速定位并解决效率瓶颈。
开启并分析慢查询日志
慢查询日志是排查性能问题的首要工具，它会记录所有执行时间超过设定阈值的SQL语句。
- 启用日志：通过命令 SET GLOBAL slow_query_log = 'ON'; 开启日志功能，并用 SET GLOBAL long_query_time = 2; 将阈值设为2秒（根据业务调整）
- 指定路径：使用 SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log'; 设置日志存储位置，确保目录有写入权限
- 查看内容：直接读取日志文件，或用 tail -f /var/log/mysql/slow.log 实时观察新产生的慢查询记录
- 统计分析：借助Percona Toolkit中的pt-query-digest工具，运行 pt-query-digest /var/log/mysql/slow.log > report.txt 生成汇总报告，找出最耗时或调用最频繁的SQL
利用Performance Schema识别热点表
MySQL 5.7及以上版本可通过Performance Schema精准追踪表级访问情况，帮助发现高频操作的“热点表”。
- 开启监控：执行命令 UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_waits%'; 启用等待事件收集
- 查询热点表：通过以下SQL查找最近被最多读取的表： SELECT object_schema, object_name, count_read FROM performance_schema.table_io_waits_summary_by_table ORDER BY count_read DESC LIMIT 10;
- 分析锁竞争：检查是否存在因热点表导致的锁等待，运行： SELECT * FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME LIKE 'wait/synch/%' AND COUNT_STAR > 0;
结合EXPLAIN优化具体查询
定位到慢SQL和热点表后，需深入分析执行计划，确认是否缺少有效索引或存在全表扫描。
- 对目标SQL前加上 EXPLAIN，观察 type 字段，若出现 ALL 表示全表扫描，应优化
- 关注 rows 值，数值越大说明扫描行数越多，性能越差
- 检查 possible_keys 和 key，确认查询是否使用了合适的索引
- 针对WHERE、JOIN、ORDER BY字段建立复合索引，并遵循最左匹配原则
基本上就这些，不复杂但容易忽略。
