直接看执行计划和运行时指标，别依赖断点单步走——在绝大多数数据库中，尤其是在MySQL里，根本不存在真正的“断点”让你停。退一步讲，就算有，SQL的性能瓶颈也从来不在于“哪一行代码卡住了”，而在于“哪一步查了十万行数据还没完”。 先聊第一个：用 `EXPLAIN ANALYZE` 替代单步执行，这适用于PostgreSQL和MySQL 8.0+ 存储过程内部跑的SQL语句，默认不会自己把执行细节给展现出来。你必须把关键查询单独抽出来，亲自分析。别只甩出一个 `EXPLAIN` 就了事，必须上 `EXPLAIN ANALYZE`，带上实际执行耗时、真实返回行数，还有磁盘溢出、临时表这些破事。 - 对PostgreSQL：跑 `EXPLAIN ANALYZE SELECT * FROM your_function(...)`，会输出每个子查询的真实耗时和行数，以及有没有溢出磁盘 - 对MySQL 8.0+：先确保 `performance_schema` 开启了，然后通过 `EXPLAIN FORMAT=JSON` 看里面的 `execution_time` 和 `rows_examined` - 注意别在存储过程里套太多层函数调用——`EXPLAIN ANALYZE` 只能穿透一层，深层逻辑只能手动拆开分析 更关键的是，查统计视图才能知道真实运行时的瓶颈 用 `pg_stat_user_functions`（PostgreSQL）或 `sys.dm_exec_procedure_stats`（SQL Server），这些系统视图记录的是真实调用后的聚合统计，比“猜哪里慢”靠得住多了。 - PostgreSQL中：`SELECT * FROM pg_stat_user_functions WHERE calls > 10 ORDER BY total_time DESC LIMIT 5`，秒懂最耗时的函数 - SQL Server中：`SELECT object_name(object_id), execution_count, total_logical_reads, total_elapsed_time FROM sys.dm_exec_procedure_stats WHERE database_id = DB_ID()`，重点关注那些 `total_logical_reads / execution_count` 偏高的过程 - 务必注意：这些数据是连接级或实例级缓存的，重启后就清零。生产环境建议配合Extended Events持续采样 参数嗅探？这坑踩了不知道多少次 同一个存储过程，换了个参数跑，性能差10倍——大概率是执行计划被缓存后，没适配新的参数分布。 - SQL Server里：加个 `WITH RECOMPILE` 强制每次重编译，或者用 `OPTIMIZE FOR` 提示指定一个典型值 - PostgreSQL里：PL/pgSQL默认缓存计划。改用 `EXECUTE 'SELECT ...' USING param` 能绕过缓存，但要注意SQL注入风险 - MySQL算省心点，没参数嗅探问题，但它有更隐蔽的查询缓存失效机制。不过8.0+移除了查询缓存，场面反而稳了 最后，别拿游标当调试工具来用 看到有同学在存储过程里加 `SELECT 'debug', @var` 或循环打印中间结果——这不仅污染输出，还可能让原本200毫秒的过程直接膨胀到2秒。高并发下简直是在自爆。 - 调试输出应该走日志表（比如 `INSERT INTO debug_log VALUES (...)`），而且只在开发环境开开关 - 真正要定位瓶颈，盯住 `rows_examined` 和 `temp_tables_created` 这类硬指标就行，不需要纠结“变量值对不对” - 如果非要用观察中间结果，优先开临时表再加 `SELECT` 查看，边算边输出这事万万不可 复杂存储过程的性能瓶颈，往往藏在“看似无害”的连接顺序、隐式类型转换、或一个没覆盖的 `ORDER BY` 字段里。执行计划不会骗人，但得你亲手把它拉出来看清楚。