Ubuntu下PHP日志中慢查询的优化方法
慢查询是PHP应用性能瓶颈的常见来源,优化需围绕“定位问题→分析根源→针对性解决→持续监控”的思路展开,覆盖数据库、PHP代码、系统配置等多层面。
慢查询日志是识别性能瓶颈的“第一手资料”,需先通过日志明确哪些SQL执行慢。
/etc/mysql/mysql.conf.d/mysqld.cnf),添加或修改以下参数:[mysqld]
slow_query_log = 1 # 启用慢查询日志
slow_query_log_file = /var/log/mysql/mysql-slow.log # 日志文件路径
long_query_time = 1 # 慢查询阈值(单位:秒,可根据业务调整)
log_queries_not_using_indexes = 1 # 记录未使用索引的查询(即使执行快)
重启MySQL服务使配置生效:sudo systemctl restart mysql。mysqldumpslow工具聚合日志,找出高频、高耗时的慢查询。例如:mysqldumpslow -s at -t 10 /var/log/mysql/mysql-slow.log
其中-s at表示按平均查询时间排序,-t 10显示前10条,结果会用N代替参数,清晰展示慢查询结构。拿到慢查询后,需用EXPLAIN命令解析其执行逻辑,定位性能瓶颈(如未走索引、全表扫描等)。
EXPLAIN关键字,例如:EXPLAIN SELECT * FROM users WHERE status = 'active' AND created_at < NOW() ORDER BY id DESC LIMIT 10;
type:应避免ALL(全表扫描),优先选择eq_ref(主键关联)、const(常量查询)等高效类型;key:是否命中索引,若为NULL则需添加索引;rows:扫描行数,数值越大说明效率越低;Extra:避免Using filesort(文件排序)、Using temporary(临时表)等耗时操作。SQL优化需结合数据库设计,减少数据库负担:
WHERE、JOIN、ORDER BY涉及的高选择性列(如状态、时间戳)创建索引,但避免过多索引(会增加写操作开销)。例如:CREATE INDEX idx_status_created ON users(status, created_at);
SELECT *,只查询需要的列;OR、NOT IN等操作,可能导致索引失效;WHERE id > last_id LIMIT n替代LIMIT offset, n(避免大偏移量扫描);JOIN。PHP代码逻辑直接影响数据库访问频率,需避免低效操作:
JOIN查询或批量获取。PHP-FPM的进程管理配置不当会导致资源浪费,需根据服务器资源调整:
/etc/php/7.x/fpm/pool.d/www.conf):pm = dynamic # 动态进程管理模式
pm.max_children = 50 # 最大子进程数(根据内存调整,如1GB内存约设20-30)
pm.start_servers = 5 # 启动时的子进程数
pm.min_spare_servers = 5 # 最小空闲子进程数
pm.max_spare_servers = 35 # 最大空闲子进程数
request_terminate_timeout = 30s # 请求超时时间(避免长时间运行脚本占用资源)
调整后重启PHP-FPM:sudo systemctl restart php7.x-fpm。OPcache可缓存PHP脚本的字节码,避免重复解析和编译,显著提升PHP执行速度:
sudo apt install php-opcache(根据PHP版本调整包名)。php.ini(如/etc/php/7.x/fpm/php.ini),添加或修改以下配置:[opcache]
zend_extension=opcache.so
opcache.enable=1
opcache.memory_consumption=128 # 缓存内存大小(MB,根据服务器调整)
opcache.max_accelerated_files=4000 # 缓存的文件数量
opcache.revalidate_freq=60 # 文件修改后重新缓存的间隔(秒)
重启PHP-FPM使配置生效。优化后需持续监控,及时发现新的性能问题:
pt-query-digest定期分析慢查询日志,跟踪慢查询的变化趋势。