php - 页面加载，MYSQL或cronjob上的PHP - 用于检查时间是否已过去？

Question

我正在做一个清单，在那里项目可以再次点击一段时间后。每个用户（可能高达100万，但可能介于10000到100000之间）的清单上最多有200个项目（可能在不同的ajax选项卡上分成不到20个的小部分），这些项目都会在不同的时间间隔后更新-有的在2分30秒，有的在1小时，有的在20小时，有的以及在特定时间而不是间隔重置的棘手问题（我认为是针对特定时间项的cronjob）。
我的数据库行将类似于：

---------------------------------------------
| UserID |  D1  |  D2  |  D3  |  D4  | D150 |
---------------------------------------------
| 345    | time | time | time | time | time |
| 7294   | time | time | time | time | time |
| 2385   | time | time | time | time | time |
---------------------------------------------

我计划用以下方法节省重置时间：

mysql_query ("INSERT INTO checklists (D1) 
VALUES ((SYSDATE() + INTERVAL 20 HOUR))") 
or die (mysql_error()); 

我认为使用sysdate（）比使用now（）更好，因为我读到now（）使用它被插入的时间，而不是调用的时间，如果有被锁定的行或now（）的内容，那么这个时间就不够精确（除非我向后调用它？）。有关此信息，请点击： https://coderwall.com/p/eslwuw/why-not-to-use-now-in-mysql。精确到毫秒并不重要，但精确到秒才重要。
所以，在我用上述代码将重置时间保存到数据库中之后，在页面上显示准确的最新清单的最有效方法是什么？
我是使用用户id的 SELECT * FROM checklists WHERE D1 < NOW()on pageload来限制搜索，还是在pageload上使用某种php脚本，或者一分钟运行几次cronjob（我怀疑这是一种合适的方法，但我认为无论如何都应该包含它）？
哪种检查方法更适合快速加载页面？哪个会给服务器带来更大的压力？
最好有100个不同的表，将列表分成块以匹配选项卡内容，如：

-----------------    -----------------    -----------------         
| UserID |  D1  |    | UserID |  D2  |    | UserID |  D10 |        
-----------------    -----------------    -----------------         
| 345    | time |    | 345    | time |    | 345    | time |
| 7294   | time |    | 7294   | time |    | 7294   | time |
| 2385   | time |    | 2385   | time |    | 2385   | time |
-----------------    -----------------    -----------------

更多信息：
用户页面将有标签，每个标签上有10-20个清单项目。
用户将单击一个按钮，显示他们完成了一项任务，即重置时间将添加到数据库中。
当他们重新加载选项卡时，它将显示是否有任何检查表项准备好再次单击。

Answer 1

“当他们重新加载选项卡时，它将显示是否有任何检查表项准备好再次单击。”——让我们从改进开始。让我们去掉重新加载标签。每个检查表项目的“剩余时间”可以逐页加载到页面上。一个相当简单的javascript函数可以每秒钟唤醒一次，遍历项目（即使是200个项目），检查哪些项目已经“超时”，并将项目从红色更改为绿色（或者您希望指示“现在是时候了！”）。同时，每个项目甚至可以有一个倒计时显示在上面。另外，请注意，将负担推到用户的浏览器上会使服务器减轻很大的负担。
一旦用户单击该项，然后返回到服务器，服务器返回到mysql以重置该计时器。
所以，回到数据库设计。
A计划：每个用户一行；200列，每个项目一列。UPDATE tbl SET item123 = ... WHERE user_id = 9876;但是，您必须“构造”sql，因为需要构造列名：item123。
方案B：每个用户每项一行。UPDATE tbl SET next = ... WHERE user_id = 9876 AND item_num = 123
这两个计划都是“有效的”；每分钟处理超过5公里的更新应该很容易。计划B会占用更多的磁盘空间。
但是，还有一个查询需要担心：加载页面。据我所知，这包括：给定一个用户id，获取200（或者仅仅20？）那个用户的计时器。
SELECT * FROM tbl WHERE user_id = 9876;
计划a（如上所定义）：select将获取一个宽行。
方案B：选择将获取200（或20）行。
不过，两者都是“有效的”，但有一个条件是：
A计划表需要PRIMARY KEY(user_id)
B计划的桌子需要PRIMARY KEY(user_id, item_num)
请记住，cronjob无法访问web页面。因此，这种设计是“扭转”。
现在来看一些数字。如果你有1000个用户在任何时候“在线”，他们平均每分钟点击一个“项目”……这是1K更新，1K选择构建重新加载的页面。2公里/分钟在我提到的5公里以内。然而，它正在突破限制——想想交通高峰，等等。所以，在如何实现方面可能需要格外小心。如果这些数字有意义的话，我们就可以做到这一点。
编辑
由于并非所有用户都拥有所有项目，让我们讨论不需要的项目占用（或不占用）空间的情况。
计划A：每个空列都有一个小的开销。
计划B：你甚至不需要有未使用的行。也就是说，一个用户最多有200行。因此，没有“浪费”空间。
增加“200”怎么样？
计划A：停机做修改表。这是A计划的一大缺点。
计划B：不需要更改架构。
RAM大小和数据集大小？
如果所有的东西都可以缓存在ram中，那么惟一的i/o就是用于写入事务日志（innodb）并最终将数据持久化到磁盘。即使活动用户的数量使得他们的行可以缓存在ram中，直到他们注销，关于i/o的评论也是正确的。
如果有更多的活动用户无法有效缓存，则进程将成为I/O绑定的，并且您将无法跟上。这可以通过（a）增加ram（和增加innodb_buffer_pool_大小）或（b）“分片”（sharding）——在多台机器上分散用户来解决。
1GB虚拟机意味着innodb_buffer_pool_的大小应该只有100M，但这可能足够大，可以处理您的预计活动负载。（正如你所说，数字是模糊的。）
多个数据库？
一个数据库中有一个表，没有分区。按数据库、表或分区进行拆分（据我所见）没有任何优势。如果你长得多，切块（上面提到的）可能会有用。不过，我还是会先强化一个服务器：两个硬件改进：更多的ram和带有写缓存的raid条带。（这些还不需要。在决定何时/是否增强硬件之前，最好先获取活动用户的指标、点击率等。）
200个连接限制？
最大连接数是200吗？或者最大用户连接？你使用的云服务不会让你增加吗？
建议您立即断开连接，而不是挂在连接上，用户在接下来的一分钟内都不会再打这个连接。您可以通过设置wait_timeout（或者它是交互式的wait_timeout？）比如说，10秒。
在添加“实例”之前，让我们尝试在这个级别解决问题。