php pdo中游标是pdostatement隐式控制的读取机制，其行为由fetch mode、fetch orientation及驱动是否支持可滚动游标决定；仅当驱动支持且业务需非顺序遍历（如分页回溯、双向遍历、强一致性迭代）时才启用。
PHP PDO 中的游标（Cursor）并不是一个独立的对象，而是由预处理语句（PDOStatement）在执行查询时隐式控制的数据读取机制。真正影响“游标行为”的是 fetch mode、fetch orientation（如 PDO::FETCH_ORI_* 常量）以及底层数据库驱动是否支持可滚动游标（scrollable cursor）。实际开发中，绝大多数场景下 PHP 应用并不需要显式使用可滚动游标，但理解其适用边界有助于规避性能陷阱和逻辑错误。
适合使用可滚动游标（Scrollable Cursor）的场景
仅当数据库驱动支持且业务逻辑明确要求“非顺序遍历结果集”时才考虑启用。例如：
- 分页回溯或动态跳转：用户在前端点击“上一页”“跳至第 100 行”，后端需从已执行的查询结果中随机定位，而非重新查库（注意：生产环境更推荐基于 WHERE + LIMIT 的真分页）
- 双向遍历对比：如逐行比对首尾记录字段（如检测对称性）、实现双指针算法（如查找两数之和），需同时访问开头与结尾位置
- 数据库层强一致性迭代：某些金融类批处理要求在单次查询快照内反复读取同一结果集的不同偏移，避免多次查询间数据变更导致不一致
PDO 中启用可滚动游标的必要条件
不是所有数据库都支持，也不是所有 fetch 模式都兼容。关键点包括：
- 驱动必须支持：MySQLi 默认不支持；PostgreSQL（通过 pgsql 驱动）、SQL Server（sqlsrv）、Oracle（oci）相对完善；MySQL 的 PDO MySQL 驱动（pdo_mysql）不支持可滚动游标（即使设置 PDO::ATTR_CURSOR = PDO::CURSOR_SCROLL，也会静默降级为 forward-only）
-
需在 prepare 阶段声明：通过 options 数组传入
PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL -
fetch 时指定方向与偏移：使用
fetch(PDO::FETCH_BOTH, PDO::FETCH_ORI_ABS, $row)或fetch(PDO::FETCH_BOTH, PDO::FETCH_ORI_REL, $offset)
绝大多数情况应避免游标，改用更高效方案
盲目开启游标易引发资源占用高、兼容性差、调试困难等问题。常见替代方式：
立即学习“PHP免费学习笔记（深入）”；
-
结果集缓存到数组：小到中等数据量（如 ≤ 1 万行）直接
$rows = $stmt->fetchAll()，后续任意索引访问，语义清晰且跨驱动稳定 -
基于键值的分页（Keyset Pagination）：用上一页最后一条记录的主键/时间戳作为下一页查询条件（如
WHERE id > ? ORDER BY id LIMIT 20），无状态、高性能、避免 OFFSET 跳跃开销 -
流式处理（Streaming）：大数据导出或 ETL 场景，用
while ($row = $stmt->fetch())逐行处理，内存恒定，无需游标
一个典型误用游标的例子
开发者试图用 scrollable cursor 实现“获取第 N 条记录”：
$stmt = $pdo->prepare("SELECT * FROM users", [PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL]);
$stmt->execute();
$user = $stmt->fetch(PDO::FETCH_ASSOC, PDO::FETCH_ORI_ABS, $n); // ❌ 多数 MySQL 环境失效
这不仅在 MySQL 下无效，还掩盖了分页设计缺陷。正确做法是用 LIMIT/OFFSET（小数据）或 keyset 分页（大数据）。
