Laravel评论表ID改为字符串后分页接口崩溃问题排查

核心原因 #

Laravel 默认分页会自动按主键（id）排序，而你的评论表id是带前缀的字符串（如CMT-1699999999999）。字符串类型的排序逻辑与整数完全不同，数据库对字符串主键的排序无法像整数主键那样高效利用索引，导致分页查询时触发全表扫描。当表中存在大量数据时，数据库需要加载所有记录进行排序，直接耗尽PHP内存或导致查询超时——这也是空表时一切正常的原因。

另外，当前ID生成逻辑在高并发场景下存在重复风险，但这不是分页崩溃的直接诱因。

解决方案 #

1. 显式指定分页排序字段 #

放弃Laravel默认的主键排序，改用created_at或updated_at这类日期字段排序，这类字段的索引效率更高，且排序逻辑符合业务需求：

// 替换原分页代码，示例：
$comments = Comment::orderBy('created_at', 'desc')->paginate(15);

如果业务必须按ID排序，可显式指定，但字符串ID的排序性能仍不如整数，优先推荐用时间字段。

2. 优化ID生成逻辑（推荐） #

当前毫秒时间戳的生成逻辑在高并发下可能出现重复ID，建议追加随机数降低重复概率：

public static function generate(string $modelType): string
{
    $prefix = self::getModelPrefix($modelType);
    $timestamp = round(microtime(true) * 1000);
    // 追加6位随机数
    $random = mt_rand(100000, 999999);
    return $prefix . '-' . $timestamp . '-' . $random;
}

3. 验证查询执行计划 #

开启Laravel查询日志，查看分页生成的SQL语句，并用EXPLAIN分析是否触发全表扫描：

DB::enableQueryLog();
$comments = Comment::paginate(15);
dd(DB::getQueryLog());

如果发现SQL包含ORDER BY id且执行计划显示无索引命中，说明必须调整排序字段。

4. 临时调整内存限制（治标方案） #

若以上优化后仍有问题，可临时提升PHP内存限制（不推荐长期依赖）：
在public/index.php顶部添加：

ini_set('memory_limit', '256M');

或修改php.ini中的memory_limit配置。

内容的提问来源于stack exchange，提问作者PioPio