mysql优化笔记
第一步 测量时间花在什么地方，无法测量就无法优化
实际地讨论两种类型的性能剖析：基于执行时间的分析和基于等待的分析。基于执行时间的分析研究的是什么任务的执行时间最长，
基于等待的分析则是判断任务在什么地方被阻塞的时间最长。
理解性能优化
1.值得优化的查询
2.异常情况
3.未知的未知
4.被掩藏的细节
对系统进行性能剖析还是建议自上而下地进行，这个可以追踪自用户发起的服务器响应的整个流程。
性能瓶颈可能有很多影响因素：
外部资源，比如调用了外部的web服务或者搜索引擎
应用需要处理大量的数据，比如分析一个超大的XML文件
在循环中执行昂贵的操作，比如滥用正则表达式
使用了低效的算法，比如使用暴力搜索算法来查找列表中的项
set @query_id=1;
select STATUS, SUM(DURATION) AS Total_R,
ROUND(
100*SUM(DURATION)/(SELECT SUM(DURATION)
FROM INFORMATION_SCHEMA.PROFILING
WHERE QUERY_ID=@query_id )
, 2) AS Pct_R,
COUNT(*) AS CALLs,
SUM(DURATION)/COUNT(*) AS "R/Call"
FROM INFORMATION_SCHEMA.PROFILING
WHERE QUERY_ID=@query_id
GROUP BY STATE
ORDERY BY Total_R DESC;
实际地讨论两种类型的性能剖析：基于执行时间的分析和基于等待的分析。基于执行时间的分析研究的是什么任务的执行时间最长，
基于等待的分析则是判断任务在什么地方被阻塞的时间最长。
理解性能优化
1.值得优化的查询
2.异常情况
3.未知的未知
4.被掩藏的细节
对系统进行性能剖析还是建议自上而下地进行，这个可以追踪自用户发起的服务器响应的整个流程。
性能瓶颈可能有很多影响因素：
外部资源，比如调用了外部的web服务或者搜索引擎
应用需要处理大量的数据，比如分析一个超大的XML文件
在循环中执行昂贵的操作，比如滥用正则表达式
使用了低效的算法，比如使用暴力搜索算法来查找列表中的项
set @query_id=1;
select STATUS, SUM(DURATION) AS Total_R,
ROUND(
100*SUM(DURATION)/(SELECT SUM(DURATION)
FROM INFORMATION_SCHEMA.PROFILING
WHERE QUERY_ID=@query_id )
, 2) AS Pct_R,
COUNT(*) AS CALLs,
SUM(DURATION)/COUNT(*) AS "R/Call"
FROM INFORMATION_SCHEMA.PROFILING
WHERE QUERY_ID=@query_id
GROUP BY STATE
ORDERY BY Total_R DESC;
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29012686/viewspace-1131351/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
设计模式：装饰模式
请登录后发表评论
登录
全部评论
