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、是否要归因来源渠道、是否要关联用户登录态。这些一旦定错，后期补数据或改结构的成本远高于初期多花两小时想清楚。