将文件拖动至此

SQL 上传 ( 0 ) x -

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

建议系统

可能存在的性能问题

问题：
运行时间少于一天，性能调整建议可能不准确。
建议：
要获得更加准确的数据，建议在运行分析器之前先让服务器运行至少一天
现状：
运行时间只有 0 天 3 小时，42 分 27 秒
使用的变量/公式：
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 中使用索引字段，这将使排序加快。
现状：
行排序率: 3.65 每秒
使用的变量/公式：
Sort_rows / Uptime
检验：
value * 60 >= 1
问题：
有太多的联合查询未使用索引。
建议：
这意味着联合查询使用全表扫描。给联合条件所用的字段增加索引将极大提高查询速度。
现状：
表联合率: 4.35 每秒，该值应低于 1 每小时
使用的变量/公式：
(Select_range_check + Select_scan + Select_full_join) / Uptime
检验：
value * 60 * 60 > 1
问题：
读取第一个索引入口比例过高。
建议：
这通常说明频繁的全索引扫描。全索引扫描虽然比全表扫描快，但在大表中仍然需要一定 CPU 周期，如果这些表有或有过大量 UPDATE 和 DELETE，运行 'OPTIMIZE TABLE' 可减少全索引扫描的次数以及提高速度。其它会减少全索引扫描的是重写查询。
现状：
索引扫描率: 9.71 每分钟，该值应低于 1 每小时
使用的变量/公式：
Handler_read_first / Uptime
检验：
value * 60 * 60 > 1
问题：
从固定位置读取数据的比例过高。
建议：
这说明很多查询需要结果排序且/或执行一次全表扫描，包括无索引的联合查询。请在合适的地方添加索引。
现状：
固定位置读取率: 3.62 每秒，该值应低于 1 每小时
使用的变量/公式：
Handler_read_rnd / Uptime
检验：
value * 60 * 60 > 1
问题：
读取下一行的比例过高。
建议：
这说明很多查询都需要全表扫描。请在合适的地方添加索引。
现状：
下一行读取率: 154.59 每秒，该值应低于 1 每小时
使用的变量/公式：
Handler_read_rnd_next / Uptime
检验：
value * 60 * 60 > 1
问题：
很多临时表被创建在磁盘上而非内存中。
建议：
增加 max_heap_table_size 和 tmp_table_size 可能会有帮助。但有些临时表总是会写入硬盘，和这些变量无关。要避免这些，您需要重写您的查询来避免 MySQL 文档中所提到的这些条件 (临时表内: 具有 BLOB 或 TEXT 字段或具有大于 512 字节的字段)
现状：
临时表硬盘写入率: 22.81 每分钟，该值应低于 1 每小时
使用的变量/公式：
Created_tmp_disk_tables / 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
问题：
打开表的比例过高。
建议：
打开表需要很耗时的磁盘 I/O。增加 table_open_cache 避免多次打开。
现状：
已打开表的比率: 36.95 每小时，该值应低于 10 每小时
使用的变量/公式：
Opened_tables / Uptime
检验：
value*60*60 > 10
问题：
当前打开文件数比率很高。
建议：
考虑增加 open_files_limit，并在修改 open_files_limit 重启后检查错误日志。
现状：
已打开文件的比率：20.5 每小时,这个值应该低于5每小时
使用的变量/公式：
Open_files / Uptime
检验：
value * 60 * 60 > 5
问题：
查询缓存使用不到 80%。
建议：
这可能是因为 query_cache_limit 太低所导致。刷新查询缓存可能会有帮助。
现状：
当前空闲查询缓存内存为总查询缓存大小的 12%。此值应高于 80%
使用的变量/公式：
100 - Qcache_free_memory / query_cache_size * 100
检验：
value < 80
问题：
查询缓存结果最大大小已设为默认值 1 MB 。
建议：
修改 query_cache_limit (通常是增加) 可能提升效率。该变量决定可能要插入到查询缓存中查询结果的最大大小。若多数超过 1 MB 的查询结果能很好的缓存 (多读、少写) 则增加 query_cache_limit 将会提升效率。若多数超过 1 MB 的查询结果不能很好的缓存 (通常因为表更新而失效) 增加 query_cache_limit 将会降低效率。
现状：
query_cache_limit 已被设为 1 MB
使用的变量/公式：
query_cache_limit
检验：
value == 1024*1024