应使用HTTP接口配合stream=1和max_block_size分块流式读取，禁用CURLOPT_RETURNTRANSFER，改用CURLOPT_WRITEFUNCTION回调处理；分页优先采用基于排序字段的where+limit、物化视图预聚合或客户端游标token方案。
PHP 连接 ClickHouse 取大结果集时内存爆掉怎么办
直接用 mysqli 或 pdo 的 fetchAll() 拿几百万行数据，PHP 进程大概率 OOM。ClickHouse 本身不支持游标式流式读取，但客户端可以通过 HTTP 接口配合 stream=1 + 分块读取绕过内存瓶颈。
- 必须用 HTTP 接口（不是 MySQL 兼容协议），因为只有 HTTP 支持
stream=1和max_block_size - 禁用
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true)，改用false+CURLOPT_WRITEFUNCTION流式消费 - 设置
max_block_size=65536（默认 1024，太小会频繁触发回调；太大又失去流控意义） - 别依赖
Content-Length判断结束——ClickHouse HTTP 响应通常不带这个头，靠curl返回值或回调返回长度为 0 判定 EOF
ClickHouse PHP 分页的三种实际可行法
“LIMIT offset, size” 在大数据量下性能断崖式下跌，因为 ClickHouse 仍要扫描前 offset 行。真正能用的只有这三种：
-
基于排序字段的 where + limit（推荐）：比如按
event_time分页，第二页就写WHERE event_time > '2024-01-01 10:00:00' ORDER BY event_time LIMIT 1000；要求字段高基数、有索引（主键或跳数索引） -
使用
SELECT ... FROM table FINAL+ 物化视图预聚合：把分页逻辑下沉到物化视图里，查视图时只扫聚合后的小结果集 -
客户端维护游标 token（如 last_id）：首次查
ORDER BY id LIMIT 1000，记下最后的id，下次传WHERE id > ? ORDER BY id LIMIT 1000；注意id必须唯一且单调递增，否则漏数据
php-clickhouse 扩展的坑：不要用 select() 直接取大结果
社区流行的 sudo/php-clickhouse 扩展封装了 HTTP 调用，但它默认把整个响应体缓存在内存里，select() 返回的是完整二维数组 —— 千万级结果直接崩。
- 绕过方法：调用底层
sendRequest()，传入自定义write_function回调，自己解析 TSV/JSONEachRow 流 - 务必设置
output_format_json_quote_64bit_integers=0，否则大整型（如 UInt64）会被包成字符串，PHP 自动转成 float 导致精度丢失 - 如果用 JSONEachRow 格式，每行是独立 JSON 对象，不能直接
json_decode($line)，得先 trim() 去首尾空白，再判断是否为空行
分页查询中 ORDER BY 字段没索引的后果
ClickHouse 的 ORDER BY 是建表时定义的排序键，不是查询时可加的索引。如果分页语句里的 ORDER BY 字段不在建表 ORDER BY 子句里，查询会退化成全表扫描 + 内存排序 —— 即使加了 LIMIT，也要先把所有匹配行读进内存再排序取前 N。
立即学习“PHP免费学习笔记（深入）”；
- 检查方式：
DESCRIBE TABLE your_table，看sorting_key是否包含你要分页的字段 - 补救办法有限：重建表（
CREATE TABLE new AS old ENGINE = ... ORDER BY (ts, user_id)），或加跳数索引（ADD INDEX idx_ts ts TYPE minmax GRANULARITY 1），但跳数索引只加速 WHERE，不加速 ORDER BY - 线上表无法重建时，只能换策略：用物化视图按需预排序，或接受首次查询慢（后续用 token 分页就快了）
分页和流式读取的关键，从来不是“怎么写 SQL”，而是“怎么让 ClickHouse 少读、少传、少排”。很多问题出在默认行为太像 MySQL，而忘了 ClickHouse 的设计哲学是列存 + 预排序 + 批处理。