应按数据库驱动动态适配 limit 语法：mysql 用 limit offset, count，postgresql/sqlite 用 limit count offset offset，sql server 用 offset-fetch；参数须强转整型并限范围防注入；count(*) 应拆为独立查询且条件复用；orm 分页仍依赖底层方言，原生查询混用需手动同步总数逻辑。
MySQL 和 PostgreSQL 的 LIMIT 语法差异怎么处理
MySQL 用 LIMIT offset, count，PostgreSQL 要 LIMIT count OFFSET offset，直接拼 SQL 会报错。不能硬写死一种格式，得按驱动动态适配。
- 用
PDO::getAttribute(PDO::ATTR_DRIVER_NAME)判断当前数据库类型 - 封装一个
buildLimitClause()函数，输入$offset和$limit，输出对应方言的子句 - 注意：SQLite 也支持
LIMIT count OFFSET offset，可和 PostgreSQL 共用逻辑；SQL Server 得走OFFSET-FETCH，需单独分支
如何避免手写分页 SQL 导致的注入风险
很多人把 $page 和 $pageSize 直接拼进 SQL 字符串，这是典型漏洞。OFFSET 和 LIMIT 参数无法用 PDO 预处理占位符（? 或 :name）绑定，必须手动校验。
- 强制转换为整型：
(int)$offset、max(1, (int)$limit) - 加范围限制：比如
$limit = min($limit, 100)，防恶意传入超大值拖垮数据库 - 不要依赖前端传来的
page计算 offset，而是用($page - 1) * $limit后再强转，避免负数或浮点数
跨数据库获取总记录数的兼容写法
COUNT(*) 本身是标准 SQL，但实际执行效率和语义可能因数据库而异。比如带复杂 JOIN 或 WHERE 的查询，在 PostgreSQL 中 COUNT(*) 可能触发全表扫描，而 MySQL 有时能走覆盖索引。
- 别在分页主查询里套
SELECT COUNT(*) FROM (…)—— SQLite 不支持子查询在 FROM 中用 COUNT，PostgreSQL 对 CTE 处理也更严格 - 拆成两条独立查询：先
SELECT COUNT(*) FROM table WHERE …，再查数据。确保 WHERE 条件字符串完全一致（建议提取为变量复用） - 如果业务允许近似值，可考虑 PostgreSQL 的
reltuples或 MySQL 的TABLE_ROWS（需查information_schema），但不适用于实时性要求高的场景
使用 Laravel 或 Doctrine 等 ORM 时分页还用自己写吗
用 ORM 并不等于自动解决多库分页——Laravel 的 paginate() 底层仍调用数据库方言生成 LIMIT，Doctrine 的 setFirstResult()/setMaxResults() 在不同平台表现一致，但COUNT 查询逻辑仍由 driver 决定。
立即学习“PHP免费学习笔记（深入）”；
- Laravel 中，只要配置了正确的
DB_CONNECTION，Model::paginate()会自动适配 MySQL/PG/SQLite 的 LIMIT 和 COUNT 行为 - Doctrine 用户要注意：若手动写 DQL 并调用
Paginator，需确认CountWalker是否支持你的自定义 JOIN 结构；某些嵌套子查询会被忽略计数 - 真正容易出问题的是“原生查询 + ORM 分页器混合使用”，比如用
DB::select()拿数据，却想用LengthAwarePaginator包装——这时总数得自己算，且必须和取数据的 WHERE 完全同步
最麻烦的不是语法切换，而是某些数据库对 NULL 排序、字符集 collation、甚至 LIMIT 0 的行为不一致，这些细节往往只在上线后某次分页跳转时暴露。
