mysql - 在数据库中存储大型二维数组，连接表时的性能问题

Question

我存储每周 24 小时的时间表，这意味着每个人都有一个 24x7 2D 数组(availability[time][day])，每人总共 168 个元素。在用户搜索中，可用性是一个过滤器，这意味着这些元素必须存储在表中(可用性)。

可用性架构的一部分:

+---------+----------------+
| Field   | Type           |
+---------+----------------+
| user_id | int(10)        |
| time    | varchar(4)     |
| mon     | tinyint(1)     |
| tue     | tinyint(1)     |
| wed     | tinyint(1)     |
| thu     | tinyint(1)     |
| fri     | tinyint(1)     |
| sat     | tinyint(1)     |
| sun     | tinyint(1)     |
+---------+----------------+

示例选择(每个用户实际上一整天都有 24 行):

+---------+------+-----+-----+-----+-----+-----+-----+-----+
| user_id | time | mon | tue | wed | thu | fri | sat | sun |
+---------+------+-----+-----+-----+-----+-----+-----+-----+
| 1       | 6am  |   1 |   0 |   1 |   1 |   1 |   0 |   0 |
| 1       | 7am  |   1 |   0 |   1 |   1 |   1 |   0 |   0 |
| 1       | 8am  |   1 |   0 |   1 |   0 |   1 |   0 |   0 |
| 1       | 9am  |   0 |   0 |   0 |   1 |   0 |   0 |   0 |
| 1       | 10am |   0 |   0 |   0 |   1 |   0 |   0 |   1 |
| 1       | 11am |   1 |   0 |   1 |   0 |   1 |   0 |   1 |
| 1       | 12pm |   1 |   0 |   1 |   1 |   1 |   0 |   1 |
+---------+------+-----+-----+-----+-----+-----+-----+-----+

我担心这个表会很大，连接和解析它会大大减慢速度。可用性过滤器将是最后应用的过滤器，但返回的潜在用户集可能仍然很大。

我的问题:

1. 是否有更有效的方法来存储此信息，以使表不那么大？序列化数组并将其保存到用户表上的一个字段(例如users.availability)是否有助于提高性能？ (会有更多解析，但会跳过大量连接)

2. 表的大小真的是一个问题吗？这是我的第一个大型应用程序，所以我不确定这个表是否真的足够大以至于值得担心。 (例如，如果返回 25 个用户，availability 表将有 4,800 个字段[不包括 user_id])

Answer 1

只有当您接近数千万行时，您才需要开始担心性能。除了您的一些过早优化之外，我在这里没有看到任何问题:)

既然您已经开始了良好的起步，那么通过走标准化路线，性能似乎还不必太担心。将计划序列化到数组中会带来太多不必要的工作:

示例:如果您想要搜索在 Y 日 X 小时安排的所有用户，该怎么办？如果将其存储在数组中，则必须单独解析每一行并搜索时间和日期。您将回到原点，并解决有关性能的严重问题。

放一个

EXPLAIN EXTENDED 

在您查询之前了解幕后发生的情况。只要您的联接按索引搜索行，您的应用程序就应该运行良好。