Yii框架本身运行效率不低，大部分性能问题都出在业务代码、数据库访问或缓存策略上。排查运行缓慢不能凭感觉，需要借助调试工具把耗时点量化出来。下面会从Yii自带的Debug Toolbar开始，再到Xdebug Profiler、日志分析和APM工具，逐步建立完整的性能定位流程。
一、用Debug Toolbar快速查看请求耗时与查询次数
Yii 2的Debug Toolbar是最容易被忽略但又最实用的排查入口。在开发环境下，它会以工具条形式展示当前请求的时间线、数据库查询、日志、缓存命中情况等信息。要启用它，需要在应用的配置文件里加入debug模块，并设置allowedIPs保证只有开发机可以访问。
$config['bootstrap'][] = 'debug';
$config['modules']['debug'] = [
'class' => 'yii\debug\Module',
'allowedIPs' => ['127.0.0.1', '::1'],
];
配置完成后刷新页面，页面底部会出现一个工具条。点击面板中的DB选项可以查看本次请求执行的所有SQL语句以及每条SQL的耗时。如果发现某条SQL执行时间超过100毫秒，或者同一个查询被重复执行几十次，基本可以确定性能瓶颈所在。Timeline面板还能按时间顺序展示应用启动、控制器执行、视图渲染等各阶段耗时，帮助你判断是数据库慢还是PHP代码慢。
很多慢请求都来自N+1查询问题。例如在循环中访问关联模型时，Yii的ActiveRecord会为每次访问生成一条新的SQL。通过Debug Toolbar的Queries列表，可以直观看到重复SQL的出现频率。定位到问题后，把关联查询改成with()方法预加载，往往能让响应时间下降一个数量级。需要注意Debug Toolbar只适合开发环境，生产环境必须关闭，否则会泄露敏感信息并拖慢页面。
二、借助Xdebug Profiler生成函数级调用树
当Debug Toolbar显示数据库查询没有问题，但CPU时间仍然很高时，就需要对PHP代码本身做剖析。Xdebug是PHP生态里最常用的调试与性能分析扩展，它的Profiler模式可以记录每个函数调用的耗时和调用关系，生成cachegrind文件供可视化工具分析。
在php.ini中开启Profiler的关键配置如下：
xdebug.mode = profile xdebug.output_dir = "/tmp/xdebug" xdebug.start_with_request = trigger
这里使用trigger模式，意味着只有带有XDEBUG_TRIGGER参数的请求才会生成剖析文件，避免所有请求都产生巨大文件。触发后，在/tmp/xdebug目录下会生成cachegrind.out.*文件。接下来可以用KCacheGrind（Linux）或Webgrind（浏览器端）打开这些文件，查看函数调用树、自耗时和总耗时，快速定位热点函数。比如某个数据清洗逻辑在循环中反复调用array_merge，或者某段正则匹配消耗了大量CPU，都能在调用树中暴露出来。
剖析结果中需要重点关注两个指标：Self Cost表示函数自身代码消耗的时间，Total Cost包括它调用的其他函数。如果某个函数的Total Cost很高但Self Cost很低，说明耗时在它的子调用中；如果Self Cost也很高，问题就出在这个函数内部。基于这个思路逐层展开，很快就能找到具体的代码行。需要注意的是Xdebug Profiler会带来一定性能开销，只应在开发或测试环境运行，不要直接用于生产流量。
三、从Yii日志与数据库慢查询日志中提取线索
线上环境通常不会开启Debug Toolbar，也不能对真实流量做Xdebug剖析，这时日志就成了最重要的依据。Yii的日志组件支持记录profile信息，可以把数据库查询的耗时单独输出到文件，便于事后分析。
'log' => [
'targets' => [
[
'class' => 'yii\log\FileTarget',
'levels' => ['profile'],
'categories' => ['yii\db\*'],
'logFile' => '@runtime/logs/db-profile.log',
],
],
],
上述配置会把所有数据库相关的profile日志写入runtime/logs/db-profile.log，内容包括SQL语句、绑定参数和执行时间。通过grep或日志分析工具统计执行时间最长的SQL，就能还原线上慢请求的查询特征。如果日志显示某条SQL耗时经常超过1秒，再结合EXPLAIN查看执行计划，通常能发现缺少索引或全表扫描的问题。
除了应用日志，数据库自身的慢查询日志也值得开启。以MySQL为例，可以动态设置slow_query_log和long_query_time：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;
慢查询日志会记录所有执行时间超过阈值的SQL，并且可以通过pt-query-digest等工具做聚合统计。把Yii日志中的SQL与MySQL慢查询日志对照，既能确认数据库层面的真实耗时，也能发现应用层是否因为连接池耗尽、锁等待等原因导致排队。还有一个实用技巧是使用Yii的Debug面板或日志记录原始的SQL语句，把它放到数据库客户端中手工执行，从而排除PHP代码的干扰。
四、接入Blackfire与Tideways等APM工具做持续分析
当项目变得复杂，手工分析日志和profiler文件效率会下降，此时可以借助外部APM工具。Blackfire和Tideways是PHP生态中比较成熟的性能分析产品，它们以扩展形式安装，能够自动收集每个请求的调用图、SQL耗时、内存占用等指标，并通过Web界面可视化展示。
以Tideways为例，安装扩展并配置API Key后，不需要修改Yii代码就能开始收集数据。它的优势在于能按请求采样，对生产环境影响较小，适合长期监控。Blackfire则更强调性能测试与对比，你可以在修改代码前后各跑一次profile，工具会直接给出性能改进或退化的百分比。两者都支持查看函数调用树和SQL执行列表，定位瓶颈的方式和Xdebug类似，但省去了手动处理文件的步骤。
无论使用哪种工具，最终还是要回到代码优化上。Yii框架常见的提速手段包括：开启路由缓存和配置缓存，减少每次请求的解析开销；用with()预加载关联模型解决N+1查询；对热点数据使用缓存组件；给常用查询字段添加索引；避免在循环中执行数据库写操作。这些方法结合前面的分析工具，可以形成一个完整的排查循环：先测量、再优化、最后再次测量验证效果。性能优化不是一次性的动作，而应该成为持续集成的必要环节。
