原生PHP项目性能治理：用AOP切面统一拦截PDO与Redis，精准定位慢查询

开篇先交代一个背景：我最近接手了一个运营了五六年的老项目，没有用框架，就是最朴素的原生 PHP，数据库操作直接 new PDO，Redis 也是伸手就 new Redis。这种代码跑三五年不出大问题都算运气好，但线上一上活动流量一起来，Mysql 慢查询日志刷了一屏，十几个接口全部告警。更要命的是，代码里没有统一的数据访问层，排查慢 SQL 得先在几十个文件里找出是哪条 SQL 打了数据库，再手工把 SQL 复制到 Navicat 里 explain，一来一回半天就没了。

所以我就想，能不能在不重构业务代码的前提下，给这个原生 PHP 项目加一层"AOP 切面"，把所有的 PDO 和 Redis 调用统一拦截下来，自动记录耗时、SQL、调用来源，慢查询一出来就能定位到具体文件和行号。折腾了两周，方案已经跑上线了，效果不错，把整个排查路径捋一遍，给同样在原生 PHP 项目里做性能治理的同行一个参考。

1. 为什么要在原生 PHP 里硬造一个 AOP：框架里的切面，老项目里用不上

先说结论：Spring 的 AOP、Laravel 的中间件、ThinkPHP 的行为扩展，本质都是"在框架帮你管理对象生命周期的基础上，往方法调用前后插入拦截逻辑"。老项目之所以难上 AOP，不是不想用，而是根本没有统一的容器和对象创建入口。

1.1 大多数老项目没有"对象统一创建"这回事

新项目用框架，Redis 实例从容器里取，MySQL 连接走 ORM，你随便打个断点都能看到框架接管了所有持久化操作的入口。但老原生项目不一样，每个文件里可能都有类似的代码：

php复制$pdo = new PDO('mysql:host=...;dbname=...', 'user', 'pass');
$stmt = $pdo->query('SELECT ...');
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

这种情况下你根本没法在 PDO 和 Redis 类动手脚，除非改类名、改所有实例化位置，那和重构没区别了。

所以做这次优化之前，我先做了一件"很土但很关键"的事：把项目里所有 new PDO 和 new Redis 的位置收敛到两个工厂方法里，比如 Database::connection() 和 Cache::redis()。就算不收敛到工厂方法，至少也得通过一个统一入口反射创建，总之必须保证"所有持久化操作都走同一个门"。这是后面做切面的绝对前提，舍此无他。

1.2 为什么不用监控工具或者数据库自带慢查询日志

有人可能会说，MySQL 本身就有 slow_query_log，Redis 也有 SLOWLOG，干嘛还要自己写一层切面？

我的经验是：数据库慢查询日志只能告诉你"哪条 SQL 慢"，告诉不了你"是哪个页面、哪个接口、哪一行代码发起这条 SQL 的"。尤其在老项目里，同名 SQL 好几处，模板拼接的 SQL 到处都是，你拿着一条慢 SQL 去代码里 grep，匹配出来十个地方，你也不知道是哪个调用的。而自己加的切面日志里带上 debug_backtrace() 的文件名和行号之后，问题直接缩小到一行代码，这才是这个方案最值钱的地方。

另外一个很实际的原因：MySQL 的 slow_query_log 阈值单位是秒，默认设置下 1 秒以下的 SQL 它根本不会记。但实际 Web 项目里大量接口变慢，是几百毫秒的 SQL 在叠加，不是单条 SQL 达到 1 秒。自己记录的毫秒级耗时日志，能更真实地反映"请求链路总耗时是怎么被数据库和 Redis 吃掉的"。

2. 自己实现切面，先从"入口收敛"开始：代理类与魔术方法的组合拳

想通上面这点之后，我就开始设计切面的实现机制。核心思路其实不复杂：业务代码最终拿到的 PDO 和 Redis 实例，不是我裸 new 出来的原生对象，而是套了一层代理逻辑的"夹心饼干"。

2.1 PHP 里做切面的三种常见姿势对比

我在动手之前认真对比了几种实现路径：

最终我选了静态代理 + __call 兜底的混合方案：对 PDO，因为方法数量有限（query、exec、prepare、quote 等），我做一个子类继承 PDO 并且重写关键方法；对 Redis 就不一样了，Redis 扩展的方法数量上百个，全量重写不现实，直接用 __call 魔术方法做一刀切拦截。

2.2 定义一个统一的计时切面，多个代理共用

为了让 DB 和 Redis 两个代理不重复写计时逻辑，我抽了一个 trait，这个 trait 里只干三件事：开始计时、执行真实操作、结束计时并记录日志。

php复制trait TimingAspect {

    protected function callWithTiming(string $type, string $operation, callable $callback, array $context = []) {
        $start = microtime(true);
        try {
            $result = $callback();
        } finally {
            $elapsedMs = round((microtime(true) - $start) * 1000, 2);
            $threshold = $context['threshold'] ?? 0;
            if ($threshold <= 0 || $elapsedMs >= $threshold) {
                $this->writeSlowLog(array_merge([
                    'time'      => date('Y-m-d H:i:s'),
                    'type'      => $type,
                    'operation' => $operation,
                    'elapsed_ms' => $elapsedMs,
                ], $context));
            }
        }
        return $result;
    }

    protected function writeSlowLog(array $row) {
        $line = json_encode($row, JSON_UNESCAPED_UNICODE);
        file_put_contents(
            $this->logFile ?? '/tmp/php_aspect.log',
            $line . PHP_EOL,
            FILE_APPEND | LOCK_EX
        );
    }
}

这里有个细节我要多说一句：$threshold 不是每个操作都要写日志，我设置成"只记录超过阈值的操作"，这个阈值可以按 SQL 和 Redis 命令分别配置。为什么不是全量记录？因为线上流量一大，全量记录意味着每秒几百条日志写到磁盘，反而拖累应用性能。

另一个细节：finally 保证即使 SQL 执行抛异常，耗时也被记录下来。异常导致慢查询在线上太常见了，如果只在正常返回时记录，会漏掉一大堆"执行到一半卡死然后报错"的问题。

3. DB 切面落地：连 prepared statement 的耗时都别放过

DB 切面第一个版本我只重写了 query() 和 exec()，上线之后发现慢查询日志少了一块：项目里有大量代码走 prepare() + execute()，而 execute() 是发生在 PDOStatement 对象上的，不经过 PDO 代理类。

3.1 重写 PDO 子类，覆盖 query / exec / prepare

先写 PDO 代理子类。

php复制class DbProxy extends PDO {

    use TimingAspect;

    protected string $logFile = '/var/log/php_db_slow.log';
    protected float $slowThreshold = 500; // ms

    public function __construct($dsn, $username = null, $password = null, $options = null) {
        parent::__construct($dsn, $username, $password, $options);
        $this->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        $this->setAttribute(PDO::ATTR_STATEMENT_CLASS, [DbStatementProxy::class, [$this]]);
    }

    public function query(string $sql, ?int $fetchMode = null, mixed ...$fetchModeArgs) : PDOStatement|false {
        return $this->callWithTiming('db', $sql, function() use ($sql, $fetchMode, $fetchModeArgs) {
            if ($fetchMode === null) {
                return parent::query($sql);
            }
            return $fetchModeArgs ? parent::query($sql, $fetchMode, ...$fetchModeArgs) : parent::query($sql, $fetchMode);
        }, ['threshold' => $this->slowThreshold, 'caller' => $this->findCaller()]);
    }

    public function exec(string $sql) : int|false {
        return $this->callWithTiming('db', $sql, fn() => parent::exec($sql), [
            'threshold' => $this->slowThreshold,
            'caller' => $this->findCaller(),
        ]);
    }

    public function prepare(string $sql, array $options = []) : PDOStatement|false {
        return parent::prepare($sql, $options);
    }

    protected function findCaller() : string {
        $trace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 6);
        foreach ($trace as $item) {
            if (isset($item['file']) && !str_contains($item['file'], 'DbProxy.php')) {
                return $item['file'] . ':' . ($item['line'] ?? '?');
            }
        }
        return 'unknown';
    }
}

这里有个很容易忽略的点：debug_backtrace() 不是免费的，在高并发场景下会带来明显的 CPU 开销。所以我把它单独用 findCaller() 方法包起来，并且默认 DEBUG_BACKTRACE_IGNORE_ARGS 忽略实参，只拿文件和行号，减少内存消耗。后面如果压测发现这个函数占用太多资源，还可以改成只在耗时超过阈值的 SQL 上才调用。

3.2 最大的坑：prepare + execute 的耗时统计不到

刚才提到，prepare() 返回的对象是 PDOStatement，业务代码拿到它之后调用 execute，计时代码完全执行不到。想在 prepare() 上拦截 execute 的耗时有两条路：

• 在 DbProxy::prepare() 里返回一个自定义 PDOStatement 子类；
• 通过 PDO::ATTR_STATEMENT_CLASS 指定 statement 类。

我用的就是第二种：在构造函数里设置了 ATTR_STATEMENT_CLASS，指向自定义的 DbStatementProxy。

php复制class DbStatementProxy extends PDOStatement {

    use TimingAspect;

    protected function __construct() {
        // PDOStatement 的构造函数是 protected，不能自己 new
    }

    public function execute(?array $params = null) : bool {
        if (is_array($params) && $params) {
            $paramsForLog = $this->maskParams($params);
        } else {
            $paramsForLog = '';
        }
        $sql = $this->queryString;
        return $this->callWithTiming('db', json_encode(['sql' => $sql, 'params' => $paramsForLog]), function() use ($params) {
            return parent::execute($params);
        }, ['threshold' => 500, 'caller' => $this->findCaller()]);
    }

    protected function maskParams(array $params) : array {
        // 生产环境不能直接把参数原样写进日志，有些参数是手机号、身份证等敏感数据
        foreach ($params as $k => $v) {
            if (is_string($v) && strlen($v) > 8) {
                $params[$k] = substr($v, 0, 4) . '****' . substr($v, -4);
            }
        }
        return $params;
    }
}

注意 PDOStatement 的构造函数是 protected，所以你不能直接 new DbStatementProxy($sql, $pdo)，必须借助 ATTR_STATEMENT_CLASS 让 PDO 自己实例化它。当初我在这卡了一晚上，一直以为是 ATTR_STATEMENT_CLASS 配置写错了，后来看了 PHP 源码才恍然大悟，这个坑值得多提一句。

3.3 为什么只拦 query / exec / prepare，却不用拦 fetch 系列

很多同学会追问，那 fetch()、fetchAll() 要不要也计时？我的经验是：不要拦。

第一，PDO 默认的缓冲查询模式下，fetch() 拿数据是直接从 PHP 内存里取的，不产生新的数据库交互；耗时的大头在于 SQL 在 MySQL 服务器上的执行时间，这已经被 execute() 和 query() 盖住了。第二，如果使用 unbuffered 模式，fetch 才可能产生网络传输阻塞，但那种模式项目里基本不会用。所以在 DB 层只需要关注 SQL 的执行算子即可，把 fetch 排除在外可以显著降低日志噪音。

4. Redis 切面落地：一条 __call 通吃所有命令

Redis 的情况和 PDO 完全不一样。PHP 的 redis 扩展方法一大堆，get、set、hGetAll、zAdd、lPop……如果全都重写一遍，代码量巨大，而且每次扩展升级加了新命令还得跟着加。所以 Redis 代理我用的策略是：动态方法全部走 __call 魔术方法，一个方法统一处理所有命令。

4.1 Redis 代理类设计

php复制class RedisProxy {

    use TimingAspect;

    protected Redis $redis;
    protected string $logFile = '/var/log/php_redis_slow.log';
    protected float $slowThreshold = 200; // redis 单命令超过 200ms 就记

    public function __construct(Redis $redis) {
        $this->redis = $redis;
    }

    public function __call(string $name, array $arguments) {
        if (!method_exists($this->redis, $name)) {
            throw new BadMethodCallException("Redis method {$name} not exists");
        }
        $command = $name . ' ' . $this->formatArguments($arguments);
        return $this->callWithTiming('redis', $command, function() use ($name, $arguments) {
            return $this->redis->{$name}(...$arguments);
        }, ['threshold' => $this->slowThreshold, 'caller' => $this->findCaller()]);
    }

    protected function formatArguments(array $arguments) : string {
        // 截断过长的参数，比如大字符串值
        $parts = [];
        foreach ($arguments as $arg) {
            if (is_array($arg)) {
                $arg = json_encode($arg, JSON_UNESCAPED_UNICODE);
            }
            $arg = (string) $arg;
            if (strlen($arg) > 64) {
                $arg = substr($arg, 0, 64) . '...';
            }
            $parts[] = $arg;
        }
        return implode(' ', $parts);
    }
}

__call 接收所有的方法调用，我先把方法名和参数拼成一行便于阅读的"伪命令"，然后 callWithTiming 里去执行真实 Redis 对象的方法。这个方案的优点非常明显：以后无论 redis 扩展加多少新命令，这个代理一行都不用改，天然适配。

4.2 分布式锁、管道、订阅这些特殊调用的处理

__call 方案最怕的不是常规命令，而是几类特殊调用：

• 管道（pipeline/multi）：业务代码里 $redis->multi(Redis::PIPELINE) 拿到的是一个 Redis 对象本身，后续在这个对象上调用命令，不会回到我们代理对象的 __call。这就意味着管道里每个命令的耗时没法逐条记录。
• 订阅（subscribe）：这是一个阻塞调用，一直监听消息队列，单次调用可能阻塞几分钟，按耗时记录它没有意义。

我的处理方案是：管道里的命令，在 multi() 返回的 Redis 对象上把日志关掉，只在管道结束时统一记录一个"批量命令总数"；subscribe、blPop、brpoplpush 这类阻塞命令单独放行不记录耗时。否则日志里每天一堆几万毫秒的"慢操作"，全部是假阳性。

php复制public function multi(int $mode = Redis::MULTI) : RedisProxy|Redis {
    $this->inPipeline = true;
    $result = $this->redis->multi($mode);
    // 这里直接返回真实 Redis 对象，管道内部命令不再走代理
    return $result;
}

这是个取舍：为了统计管道内每一条命令的耗时，我可以再做一层包装，但会让代码复杂度大幅提升，而实际收益很小。项目里管道本身设计出来就是批量快速执行的，两条命令合起来才比以前一条慢。我更倾向于在管道完成之后，由 exec() 方法的返回做整体耗时统计。

4.3 连接耗时要单独分开

Redis 的 pconnect 长连接在进程存活期间只会建立一次连接，而 connect 短连接每次请求都会握手。我把连接建立的耗时独立记录到另一个日志字段里，不和具体命令耗时混在一起。

因为连接耗时高可能是网络问题、Redis 负载高、或者达到了 maxclients 上限，这种情况下后端命令平均执行时间可能只有 0.1ms，但连接已经超时了。日志里如果只看到命令耗时而不看连接耗时，会误判成"Redis 命令慢"，实际却是连接池打满。我建议在代理类构造函数里这样补一下：

php复制public function __construct(Redis $redis, bool $isPersistent = false) {
    $this->redis = $redis;
    $this->isPersistent = $isPersistent;
}

public function connect(string $host, int $port = 6379, float $timeout = 0): bool {
    if ($this->isPersistent) {
        $start = microtime(true);
        $result = $this->pconnect($host, $port, $timeout);
        $this->recordConnection($start, 'pconnect');
        return $result;
    }
    $start = microtime(true);
    $result = $this->redis->connect($host, $port, $timeout);
    $this->recordConnection($start, 'connect');
    return $result;
}

5. 从耗时日志到慢查询：怎么从一堆数字里捞出真正需要优化的 SQL

切面日志上线后，每天产生的记录不少，如果只是把日志写下来不分析，那这个切面就白做了。我的第三周时间基本花在了分析脚本上。这个部分我讲讲我是怎么利用日志定位慢查询的，以及最终处理效果。

5.1 日志字段设计：必须能回答五个问题

我最终落地的日志字段是这些：

有了 caller 字段，做慢查询治理时就不用再去代码里猜了。比如某一天日志显示 orderService.php:183 有一条 1200ms 的 SQL，直接打开这个文件第 183 行，就是那条 SELECT * FROM orders WHERE user_id = ? ORDER BY created_at DESC。

5.2 一个极简的日志聚合分析脚本

拿到一天的慢日志之后，怎么找出"最值得优化的 Top 10"？我写了一个很小的 PHP 聚合脚本，按 SQL 模板（去掉参数只保留骨架）分组，统计每个模板的总耗时和平均耗时。

php复制$lines = file('/var/log/php_db_slow.log', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
$stats = [];
foreach ($lines as $line) {
    $row = json_decode($line, true);
    if (!$row) continue;
    $sql = preg_replace('/\b\d+\b/', '?', $row['operation']);
    $key = $sql;
    if (!isset($stats[$key])) {
        $stats[$key] = ['count' => 0, 'total_ms' => 0, 'max_ms' => 0, 'caller' => $row['caller'] ?? '', 'sql' => $row['operation']];
    }
    $stats[$key]['count']++;
    $stats[$key]['total_ms'] += $row['elapsed_ms'];
    $stats[$key]['max_ms'] = max($stats[$key]['max_ms'], $row['elapsed_ms']);
}
usort($stats, fn($a, $b) => $b['total_ms'] <=> $a['total_ms']);
foreach (array_slice($stats, 0, 10) as $s) {
    printf("%8dms avg %8dms count %6d %s [%s]\n",
        $s['total_ms'], (int)($s['total_ms'] / $s['count']), $s['count'], $s['sql'], $s['caller']);
}

这个脚本是纯手写的，不需要装任何依赖，放到服务器上 php analyze.php 就能跑。它把带具体 ID 的 SQL 归一化成模板，然后按"总耗时"排序，因为你优化一条被执行了一万次但每次都只慢 50ms 的 SQL，比优化一条只执行一次但耗时 2 秒的 SQL 收益高得多。

5.3 和 MySQL slow log 结合使用的进阶玩法

自建的耗时日志只能告诉你"客户端视角的慢操作"，但 SQL 为什么慢，还得看数据库服务端视角。我的做法是：把自建日志里慢 SQL 的执行计划拿过来，用 EXPLAIN 分析。

例如某天聚合脚本输出了一个高频慢 SQL：

sql复制SELECT * FROM orders o LEFT JOIN order_items i ON o.id = i.order_id WHERE o.status = 1 ORDER BY o.pay_time DESC LIMIT 20

EXPLAIN 结果中 o 表 type=ALL，rows 达到 80 万，这就是典型的没走索引。优化方案是给 status 和 pay_time 建联合索引，LEFT JOIN 的关联字段本来就有索引，建完之后单次查询从 800ms 降到 15ms，一天几万次调用，效果立竿见影。

而 MySQL 自带的 slow_query_log 虽然在服务端记录，但配合我们的客户端调用链日志，就能完美回答"这条 SQL 从哪里来"这个问题，两者互补，缺一不可。

6. 上线两周后踩过的坑：耗时统计本身也会成为瓶颈

切面方案上线之后，我自己也被上了一课。本来是为了排查线上问题，结果切面日志在某个高峰期反而拖慢了接口响应。下面这些坑是真实踩过的，写出来帮大家少走弯路。

6.1 日志写入 O_NONBLOCK 与磁盘 IO 的平衡

我第一版 writeSlowLog() 直接用 file_put_contents(..., FILE_APPEND | LOCK_EX)，在每秒几十条慢日志时完全没压力，但流量一涨，日志频率到了每秒两三百条，文件写入就成了瓶颈。

后来改成"先写内存缓冲，每 5 秒或者每 500 条刷一次磁盘"。这个优化在 PHP-FPM 场景下需要跨请求共享缓冲，我对接的是 Swoole 常驻内存模式，直接在全局静态数组里缓冲；如果是传统 PHP-FPM，可以用 Redis 列表做缓冲队列，异步脚本消费落盘。后者虽然引入了一个额外组件，但比写文件稳定很多。

php复制// FPM 场景下：推入 Redis 队列异步落盘
$redis->lPush('slow_log_queue', json_encode($row, JSON_UNESCAPED_UNICODE));

这个改动后，应用侧耗时统计基本无感，日志从采集到落盘延迟不超过 1 秒，排查时完全够用。

6.2 阻塞型命令的误报问题

Redis 侧最大的误报来源是 blPop、brpoplpush 这类阻塞命令。业务代码里使用消息队列时，blPop 就是设计成"等消息来了再返回"，阻塞 30 秒都是正常的。如果切面把它记为慢操作，日志里每天会多出一堆无关紧要的告警，真正的问题反而被淹没。

我的解决办法是在 __call 里维护一个"忽略统计方法名单"：

php复制private array $ignoredMethods = ['blPop', 'brpop', 'brpoplpush', 'subscribe', 'psubscribe', 'xRead', 'xreadgroup'];

这些方法仍然正常执行，但 callWithTiming 里的 threshold 直接设成 PHP_INT_MAX，等效于不记录耗时。如果哪天需要排查队列消费超时，我再单独开一个开关去记录它们，默认关掉。

6.3 参数脱敏不能靠自觉

慢日志里如果出现了用户手机号、身份证号，那是妥妥的合规事故。第一版日志我把 SQL 参数里的字符串直接拼接进去，结果第二天同事告诉我日志文件里全是用户手机号。

后来我加了一个字段级的脱敏方法：数字型参数超过 6 位就中间打星号，字符串型参数超过 4 个字符的保留头尾各 2 个字符。而且这个脱敏逻辑不是写在 DbProxy 里，而是统一写在 trait 里，保证 Redis 命令中的 value 也被处理。这点建议所有做类似方案的同学都认真搞一下，不是怕自己人看到，是怕日志被拖库。

6.4 线上压测验证性能损耗：压测数据说话

最后给个压测数字：我用 ab 工具对一个原生 PHP 接口做了对比压测，这个接口里包含 3 条 SQL 和 5 次 Redis 调用。不加切面时 QPS 约 1460，加了切面（阈值以下的慢操作不写入日志，只做 microtime 计算）之后 QPS 约 1380，性能损耗大概 5.5%。在开启 debug_backtrace 的情况下，QPS 掉到了 1210，损耗接近 17%。

所以我的最终配置是：默认不开启 findCaller()，只记录 SQL 和耗时；只有遇到无法定位来源的慢操作时，临时打开一个 APP_ASPECT_CALLER_TRACE=1 环境变量，开了之后下次慢日志自动带上调用文件行号。在这种配置下，线上性能损耗基本可以忽略，而排查问题的效率成倍提升。

后来我又把整套方案继续扩展了一下：给日志加上了简单的采样率配置，某些高流量接口可以设置 10% 采样，进一步压低损耗；还把每天的慢日志聚合结果用 crontab 发到了内部群。现在这个原生 PHP 项目虽然还不算优雅，但至少"哪里慢、为什么慢"这个问题，从过去的一天排查一次，变成了五分钟定位直接改。