汇总：海量数据存储常见分表算法

　　用于大量数据存储的常用子表算法

　　当应用程序具有大量数据时，我们使用单个表和单个数据库来存储它会严重影响操作速度，例如我们已经测试了mysql myisam存储，当200w或更少时，mysql访问速度非常快，但是如果数据超过200w，其访问速度将急剧下降，从而影响我们的webapp的访问速度；如果数据量太大，则如果使用单个表进行存储，系统将相当不稳定。 mysql服务非常容易挂断。因此，当数据量超过200w时，建议系统工程师仍考虑子计量。

　　以下是几种常见的表拆分算法：

　　（[1）根据自然时间划分表/数据库

　　如果一个应用程序的数据量在一年内将达到200w左右，那么我们可以考虑使用一年的数据作为表或库来存储它，例如，如果该表名为app，那么2010年的数据数据为app_2010，app_2011；如果一个月内的数据量达到200w，那么我们可以将其除以月份，即app_2010_01，app_2010_02.

　　（[2）根据数字类型哈希子表/子数据库

　　如果我们要存储用户信息，我们的应用程序的注册量非常大，并且无法满足单个表的存储要求，那么我们可以使用用户号进行哈希处理，常见的是使用剩余操作，如果我们要将用户信息存储在30个表中，则用户1％30 = 1且用户号为1，那么我们会将其存储在user_01表中，如果用户号为500，则500％ 30 = 20，那么我们只需将用户信息存储在user_20的表中即可。

　　（[3）根据子表/子库的md5值

　　我们假设我们要存储用户上传的文件。如果上传量很大，也会导致系统瓶颈。我们已经做过实验。如果一个文件夹中有200个以上的文件，则文件的浏览效率将降低。当然，这不属于本文讨论的范围，该块也需要进行哈希处理。我们可以将文件的用户名使用md5或使用文件的md5校验和来执行，我们可以使用md5的前5位数字进行哈希处理，这样最多可以得到5 ^ 5 = 3125个表。存储文件时，我们可以使用文件名md5值的前5位数字来确定文件应存储在哪个表中。

　　（4）示例：关于微博的URL加密算法和存储策略的猜测

　　许多微博现在都使用这种URL进行访问。如果他们的域名是，那么如果您在微博上发布，您会发现您发布的所有URL均已变为。他们以这种形式做什么？如何执行这种转换？我猜它使用了我们上面提到的md5存储和搜索规则。使用您发送的URL执行md5。在获得md5值后，如我们的示例所示，将使用前6位数字。子表。

　　（[5）子表引起的问题

　　拆分表还会带来一系列问题，例如分页的实现，统计的实现，如果要对所有数据进行分页，则必须再次遍历每个表，因此访问效率将会非常低。在尝试使用mysql代理实现它之前，最后使用tcsql对其进行了实现。

　　（6）子表算法的选择

　　如果您的应用程序数据量不是特别大，则最好不要使用子表。