MySQL无页面访问统计功能，需业务层记录日志；应建单独库、用MyISAM/ARCHIVE引擎、精简字段、避免url普通索引；UV/PV宜预聚合到分区汇总表；SHOW PROCESSLIST不显示HTTP路径，因它只反映SQL执行而非页面请求。
MySQL 本身不自带页面访问统计功能，必须靠业务层记录 + 合理建表 + 定期聚合查询来实现；直接查 information_schema 或 performance_schema 只能看到连接/语句执行情况，不是“用户访问页面”意义上的统计。
怎么设计访问日志表才不拖慢业务
高频写入的访问日志如果和主业务表混用或索引滥用，会显著拖慢 INSERT 性能，尤其在并发高时：
- 用单独库（如
analytics）存日志表，避免锁竞争 - 表引擎选
MyISAM或ARCHIVE（只追加、不更新），比InnoDB写入快 2–3 倍（但注意：MyISAM不支持事务，ARCHIVE不支持索引） - 字段尽量精简：
id（自增）、url（VARCHAR(255)）、referer（可选）、ua_hash（BINARY(16)存 MD5 后的 UA，省空间）、created_at（INT存时间戳，非DATETIME） - 不要给
url加普通索引——写入时维护成本高；真要查某路径，用WHERE url LIKE '/article/%'配合覆盖索引（如联合索引(created_at, url)）更实际
如何快速查出“昨天每个页面的 UV 和 PV”
UV（独立访客）需去重，PV（页面浏览）是总行数，直接 COUNT(DISTINCT ip) 在大数据量下极慢；推荐预聚合 + 按天分区：
- 每天凌晨跑一次脚本，把昨日原始日志按
url+ip去重后写入汇总表page_stats_daily，字段含：stat_date、url、pv、uv - 汇总表主键设为
(stat_date, url)，查询秒出 - 若临时要查，可用
SELECT url, COUNT(*) AS pv, COUNT(DISTINCT ip) AS uv FROM access_log WHERE created_at >= 1735689600 AND created_at ，但数据超 500 万行就明显卡顿
为什么用 SHOW PROCESSLIST 看不到用户访问的页面
SHOW PROCESSLIST 显示的是当前 MySQL 连接正在执行的 SQL，不是 HTTP 请求路径。常见误解：
- 它看到的是类似
SELECT * FROM users WHERE id = 123，而非/user/profile -
performance_schema.events_statements_summary_by_digest能看 SQL 模板频次，但无法关联到前端路由 - 真正想分析“哪个页面最慢”，得在应用层埋点（如记录请求开始/结束时间、URL、SQL 执行耗时），再把日志导进 MySQL 或专用分析系统（如 ClickHouse）
真实项目里，最难的不是建表或写 SQL，而是决定“哪些维度值得统计”——比如是否要区分移动端/PC、是否要归因来源渠道、是否要关联用户登录态。这些一旦定错，后期补数据或改结构的成本远高于初期多花两小时想清楚。
