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 万行就明<a style="color:#f60; text-decoration:underline;" title="显卡" href="https://www.php.cn/zt/16134.html" target="_blank">显卡</a>顿
为什么用 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、是否要归因来源渠道、是否要关联用户登录态。这些一旦定错，后期补数据或改结构的成本远高于初期多花两小时想清楚。
