Question

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

availabilities架构的一部分：

+---------+----------------+
| 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 |
+---------+------+-----+-----+-----+-----+-----+-----+-----+

我担心的是这个表格会非常庞大，加入和解析它会使事情变得非常缓慢。可用性过滤器将是应用的最后一个过滤器，但返回的潜在用户集可能仍然很大。

我的问题：

是否有更有效的方法来存储此信息，以便表格不会那么大？序列化数组并将其保存到用户表上的一个字段（例如users.availability）是否有助于提高性能？（会有更多的解析，但会跳过大量的连接）
表的大小真的是一个问题吗？这是我的第一个大型应用程序，所以我不确定这个表是否真的足够大而不用担心。（例如，如果返回25个用户，availability表将有4,800个字段[不包括user_id]）

Answer 1

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

由于你已经开始了正确的步伐，看起来，通过规范化的路线，性能不应该太过关注。将计划序列化为数组将是太多不必要的工作：

示例：如果您想搜索Y天X小时的所有用户，该怎么办？如果它存储在一个数组中，则每个行都必须单独解析和搜索时间和日期。你会回到原点 - 解决对表现的严重担忧。

放一个

EXPLAIN EXTENDED

在您查询之前，看看幕后发生了什么。只要您的联接按索引搜索行，您的应用就应该飞。

在DB中存储大型2D阵列时，在连接表时会出现性能问题

1 个答案: