删除一个计数器实际会碰到什么
在这里删除一个计数器会清空 33 张表。昨天它清空 25 张。 它漏掉的那八张，全都是前一天建的，时间在上午 11:10 到下午 15:10 之间。 33 张表知道计数器的某些事 其中 8 张没有被清空 — 全都是前一天建的 这八张里一共躺着 4,840 行 今天补上，放在字母顺序的位置，不是追加到末尾 在其他表里找到 25 行孤儿行，已清除 删除是怎么做的…
备份被完整地还原了一次
这台服务器从 8 月 11 日起每天夜里给自己做备份。日志有 163 行。「还原」这个词一行都没出现过，因为每一行讲的都是写入。 今天把读取的那一半也走了一遍。 夜间备份会检查什么 退出码 · 至少 1 MB · 对面的字节数 · 一行日志 它能读回来吗？— 163 行日志，一次也没有 今天还原：从 437 MB 的导出里取出 104 MB 计数器数据 38 张表里的 38…
永远为真的那个检查
这个服务里有 23 条 UPDATE 语句。其中恰好有一条会去看自己是否改动了什么。那个检查是这样的： 'success' => $n->rowCount() >= 0 没有任何一行匹配时，rowCount() 返回 0。零大于或等于零。无论发生什么，这个检查都通过。 23 条 UPDATE 语句，其中一条会看结果 rowCount() >= 0 — 一行都没匹配到时也通过…
加索引反而更慢的时候
存放每日数字的那张表只有一个键：计数器和日期合在一起。代码里有五处向它提的是另一个问题 — 不是「这个计数器随时间的变化」，而是「这些日子里的所有计数器」。首页的展示区、排行榜、站点地图、一张 90 天的图表，还有状态数字。日期列上没有索引时，它们每一个都要读完全部 114,113 行。 加上那个索引，展示区快十倍。我们没有加。下面是做出这个决定的测量。 展示区，一天 —…
数据库结构实际存在哪里
这个服务所做的一切都在版本控制里。至少代码是。它运行其上的数据库是 32 张表，其中 15 张在仓库里任何地方都没有定义 — 没有 CREATE TABLE，没有结构文件，什么都没有。一份备份能把 32 张表连同结构一起还原；仓库里缺的，是这份结构的第二份、独立的副本。 17 张表有定义 15 张哪里都没有 21 个索引由代码创建 11 个只在库里 32 张表，32…
并不是每张表都存着三十天
这里的统计页面不是一张表，而是十二张，一个问题一张 — 国家、页面、浏览器、小时、设备、操作系统、语言、地区、来源、机器人、屏幕分辨率，还有每日总数。在顶部选一个时间段，每个面板都按这个时间段作答。 只是并非所有面板都能按同一个时间段作答，因为它们背后的表往回追溯的深度并不一样。2026 年 8 月 26 日清点： 表行数最早的一天跨度 每日总数113…
为什么页面列表里有五分之一写着 N/A
统计页面上的页面列表指明访问落在了哪些页面上。2026 年 8 月 26 日，这张表有 101 485 行，其中 20 055 行 — 19,8 % — 把页面记成了 N/A。 这不是故障，也不是缺了一个页面。这是本服务老老实实地记下：它不知道。 真实的页面地址20,055 — N/A在页面表的 101,485 行中 101,485 页面地址是从哪来的…
计数器编号现在会对两张表都做检查
这里的每个计数器都有一个编号。它写在嵌入代码里、写在统计页地址里，也写在站长贴过它的每一个页面上。编号是这样发出去的：在 100 到 9 999 999 999 之间取一个随机数，然后检查它有没有被占用。 检查的是一张表。 另外那张表 长期没有访问记录的计数器会被移进一张归档表。这是普通的整理工作——它让活动表保持小巧，让针对它的查询保持快速。2026 年 8 月 24…
从 Stats4U 2 留下来的三个字段
这里的计数器主表有 166 436 行，还有若干看起来很要紧的字段。其中三个是 lastdomain、firstdomain 和 userdomain。它们里面装着数据： lastdomain在 15 525 行里非空 firstdomain在 15 457 行里非空 userdomain在 2 982 行里非空 计数器行数：…
比字段还长的页面地址
2026 年 8 月 9 日，有二十张计数器图片没能画出来。不是画错了，也不是画得慢——访客在本该有计数器的位置什么也没拿到。 原因是一个超过 255 个字符的页面地址。现在它在写入时就被截断，计数器图片不再取决于告诉它的那个地址有多长。 这条链 记录一次访问落在哪个页面上的那个字段是 varchar(255)。地址来的时候比这更长。插入以 SQLSTATE 22001…