将文件拖动至此

SQL 上传 ( 0 ) x -

页面相关设置 点击以滚动到页面顶部
按 Ctrl+Enter 键执行查询 按 Enter 执行查询
递增排序
递减排序
命令：
调试 SQL
数量
运行顺序
用时
排序条件：
联合查询
不使用联合查询
崩溃 扩展 显示跟踪 隐藏跟踪 数量 : 用时 :
书签
刷新
添加
没有书签
添加书签
选项
恢复默认





崩溃 扩展 重新查询 编辑 解析 性能分析 书签 查询失败 数据库 : 查询时间 :

建议系统

可能存在的性能问题

问题：
运行时间少于一天，性能调整建议可能不准确。
建议：
要获得更加准确的数据，建议在运行分析器之前先让服务器运行至少一天
现状：
运行时间只有 0 天 9 小时，9 分 1 秒
使用的变量/公式：
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'
问题：
从源代码编译，不是 MySQL 官方二进制。
建议：
如果您没有从源代码编译，您可能使用了再发行的修改版本。MySQL 手册仅适用于官方二进制，而非其它再发行包 (如 RedHat、Debian/Ubuntu 等等)。
现状：
版本注释中含有 'source'
使用的变量/公式：
version_comment
检验：
preg_match('/source/i',value)
问题：
过多排序引发临时表创建。
建议：
根据系统内存限制，考虑增加 sort_buffer_size 和/或 read_rnd_buffer_size。
现状：
临时表创建率: 2.16 每分钟，该值应低于 1 每小时。
使用的变量/公式：
Sort_merge_passes / Uptime
检验：
value * 60 * 60 > 1
问题：
大量行被排序。
建议：
大量行排序不是什么错误，但您应确保需要大量排序的查询在 ORDER BY 中使用索引字段，这将使排序加快。
现状：
行排序率: 57.51 每秒
使用的变量/公式：
Sort_rows / Uptime
检验：
value * 60 >= 1
问题：
有太多的联合查询未使用索引。
建议：
这意味着联合查询使用全表扫描。给联合条件所用的字段增加索引将极大提高查询速度。
现状：
表联合率: 3.82 每秒，该值应低于 1 每小时
使用的变量/公式：
(Select_range_check + Select_scan + Select_full_join) / Uptime
检验：
value * 60 * 60 > 1
问题：
读取第一个索引入口比例过高。
建议：
这通常说明频繁的全索引扫描。全索引扫描虽然比全表扫描快，但在大表中仍然需要一定 CPU 周期，如果这些表有或有过大量 UPDATE 和 DELETE，运行 'OPTIMIZE TABLE' 可减少全索引扫描的次数以及提高速度。其它会减少全索引扫描的是重写查询。
现状：
索引扫描率: 17.52 每分钟，该值应低于 1 每小时
使用的变量/公式：
Handler_read_first / Uptime
检验：
value * 60 * 60 > 1
问题：
从固定位置读取数据的比例过高。
建议：
这说明很多查询需要结果排序且/或执行一次全表扫描，包括无索引的联合查询。请在合适的地方添加索引。
现状：
固定位置读取率: 16.58 每秒，该值应低于 1 每小时
使用的变量/公式：
Handler_read_rnd / Uptime
检验：
value * 60 * 60 > 1
问题：
读取下一行的比例过高。
建议：
这说明很多查询都需要全表扫描。请在合适的地方添加索引。
现状：
下一行读取率: 136.35 每秒，该值应低于 1 每小时
使用的变量/公式：
Handler_read_rnd_next / Uptime
检验：
value * 60 * 60 > 1
问题：
很多临时表被创建在磁盘上而非内存中。
建议：
增加 max_heap_table_size 和 tmp_table_size 可能会有帮助。但有些临时表总是会写入硬盘，和这些变量无关。要避免这些，您需要重写您的查询来避免 MySQL 文档中所提到的这些条件 (临时表内: 具有 BLOB 或 TEXT 字段或具有大于 512 字节的字段)
现状：
临时表硬盘写入率: 46.47 每分钟，该值应低于 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 避免多次打开。
现状：
已打开表的比率: 54.65 每分钟，该值应低于 10 每小时
使用的变量/公式：
Opened_tables / Uptime
检验：
value*60*60 > 10
问题：
太多的客户端已中止。
建议：
客户端中止通常是因为它们没有正确关闭到 MySQL 服务器的连接。这可能由网络问题或代码中没有正确关闭数据库连接引起。请检查您的网络和代码。
现状：
客户端取消率为 1.31 每小时，此值应低于 1 每小时
使用的变量/公式：
Aborted_clients / Uptime
检验：
value * 60 * 60 > 1
问题：
查询缓存没有启用。
建议：
若正确设置查询缓存将带来性能上的极大提升。您可以通过设置 query_cache_size 为 2 位数的 MB 值和设置 query_cache_type 为 'ON'。注意: 若您正在使用 memcached，请忽略此建议。
现状：
query_cache_size 被设为 0 或 query_cache_type 被设为 'OFF'
使用的变量/公式：
query_cache_size
检验：
value == 0 || query_cache_type == 'OFF' || query_cache_type == '0'