将文件拖动至此

SQL 上传 ( 0 ) x -

页面相关设置 点击以滚动到页面顶部
按 Ctrl+Enter 键执行查询 按 Enter 执行查询
递增排序
递减排序
命令：
调试 SQL
数量
运行顺序
用时
排序条件：
联合查询
不使用联合查询
崩溃 扩展 显示跟踪 隐藏跟踪 记录数： 用时：
选项
还原为默认值
崩溃 扩展 重新查询 编辑 解析 性能分析 查询失败 数据库: 查询时间:

建议系统

可能存在的性能问题

问题：
运行时间少于一天，性能调整建议可能不准确。
建议：
要获得更加准确的数据，建议在运行分析器之前先让服务器运行至少一天
现状：
运行时间只有 0 天 0 小时，0 分 17 秒
使用的变量/公式：
Uptime
检验：
value < 86400
问题：
long_query_time 当前设为 10 秒或更长，因此超过 10 秒的查询才被记为慢查询。
建议：
建议根据您的环境将 long_query_time 调短。通常建议设为 1-5 秒。
现状：
long_query_time 当前被设为 10 秒。
使用的变量/公式：
long_query_time
检验：
value >= 10
问题：
慢查询记录已禁用。
建议：
请将 slow_query_log 设为 'ON' 来启用慢查询记录。这将有助于解决查询问题。
现状：
slow_query_log 被设为 'OFF'
使用的变量/公式：
slow_query_log
检验：
value == 'OFF'
问题：
大量行被排序。
建议：
大量行排序不是什么错误，但您应确保需要大量排序的查询在 ORDER BY 中使用索引字段，这将使排序加快。
现状：
行排序率: 243.35 每秒
使用的变量/公式：
Sort_rows / Uptime
检验：
value * 60 >= 1
问题：
有太多的联合查询未使用索引。
建议：
这意味着联合查询使用全表扫描。给联合条件所用的字段增加索引将极大提高查询速度。
现状：
表联合率: 102.35 每秒，该值应低于 1 每小时
使用的变量/公式：
(Select_range_check + Select_scan + Select_full_join) / Uptime
检验：
value * 60 * 60 > 1
问题：
读取第一个索引入口比例过高。
建议：
这通常说明频繁的全索引扫描。全索引扫描虽然比全表扫描快，但在大表中仍然需要一定 CPU 周期，如果这些表有或有过大量 UPDATE 和 DELETE，运行 'OPTIMIZE TABLE' 可减少全索引扫描的次数以及提高速度。其它会减少全索引扫描的是重写查询。
现状：
索引扫描率: 47.18 每秒，该值应低于 1 每小时
使用的变量/公式：
Handler_read_first / Uptime
检验：
value * 60 * 60 > 1
问题：
从固定位置读取数据的比例过高。
建议：
这说明很多查询需要结果排序且/或执行一次全表扫描，包括无索引的联合查询。请在合适的地方添加索引。
现状：
固定位置读取率: 18.71 每秒，该值应低于 1 每小时
使用的变量/公式：
Handler_read_rnd / Uptime
检验：
value * 60 * 60 > 1
问题：
读取下一行的比例过高。
建议：
这说明很多查询都需要全表扫描。请在合适的地方添加索引。
现状：
下一行读取率: 5445.71 每秒，该值应低于 1 每小时
使用的变量/公式：
Handler_read_rnd_next / Uptime
检验：
value * 60 * 60 > 1
问题：
MyISAM 索引缓存 % 使用率低。
建议：
您可能需要减小 key_buffer_size 的大小，重新检查您的表是否删除了索引或检查查询期望使用的索引。
现状：
最大 % MyISAM 索引缓存从未使用: 0%，该值应高于 95%
使用的变量/公式：
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
检验：
value < 95
问题：
% 使用索引缓存的比例是低的。
建议：
你需要增大 key_buffer_size。
现状：
从内存读取索引率: 0%，该值应高于 95%
使用的变量/公式：
100 - (Key_reads / Key_read_requests * 100)
检验：
value < 95
问题：
打开表的比例过高。
建议：
打开表需要很耗时的磁盘 I/O。增加 table_open_cache 避免多次打开。
现状：
已打开表的比率: 22.35 每秒，该值应低于 10 每小时
使用的变量/公式：
Opened_tables / Uptime
检验：
value*60*60 > 10
问题：
当前打开文件数比率很高。
建议：
考虑增加 open_files_limit，并在修改 open_files_limit 重启后检查错误日志。
现状：
已打开文件的比率：14.12 每分钟,这个值应该低于5每小时
使用的变量/公式：
Open_files / Uptime
检验：
value * 60 * 60 > 5