我的项目的一部分涉及在我的数据库中存储和检索大量 ips。我估计在项目启动后的几个月内我的数据库将拥有数百万个 ip。既然如此，我想知道对大型数据库的简单查询有多慢？以下查询的大致速度是多少：
SELECT * FROM table where ip= '$ip' LIMIT 1
INSERT INTO table(ip, xxx, yyy)VALUES('$ip', '$xxx', '$yyy')
在有 2.65 亿行的表上？
我可以通过创建 255^2 个表来加快查询速度，这些表的名称对应于所有可能的 ipv4 ip 地址的所有前两个数字，然后每个表最多有 255^2 行，可以容纳所有可能的第二部分到ip。因此，例如要查询 IP 地址“216.27.61.137”，它将被分成两部分，“216.27”（p1）和“61.137”（p2）。首先，脚本会选择名称为 p1 的表，然后它会检查是否有任何名为“p2”的行，如果有，它将从该行中提取所需的数据。将使用相同的过程将新的 ips 插入数据库。
如果上述计划不起作用，那么在大型数据库中加快查询速度的好方法是什么？
这两个问题的答案都取决于INDEXES.
如果你的表在ip你的第一个查询中被索引，无论你的表有多大，都应该或多或少地立即执行：MySQL 将使用索引。您的第二个查询会变慢，因为 MySQL 必须更新每个INSERT.
如果你的表没有被索引，那么第二个查询将几乎立即执行，因为 MySQL 可以在表的末尾添加行。您的第一个查询可能无法使用，因为 MySQL 每次都必须扫描整个表。
问题是平衡。添加索引将加快第一个查询，但减慢第二个查询。究竟会发生什么将取决于服务器硬件、您选择的数据库引擎、MySQL 的配置以及当时正在发生的其他事情。如果性能可能很关键，请先进行一些测试。
在进行任何此类操作之前，请阅读这个问题（更重要的是）它的答案：How to store an IP in mySQL
在多个表之间拆分数据通常不是一个好主意。数据库索引擅长它们的工作，因此只需确保相应地创建它们。存储 IPv4 地址的二进制列会很好地工作 - 它更多的是查询负载问题而不是表大小问题。
首先，您无法预测查询需要多长时间，即使我们知道有关数据库、数据库服务器、网络性能和另外数千个变量的所有信息。
其次，如果您使用的是不错的数据库引擎，则不必将数据拆分到不同的表中。它知道如何处理大数据。将数据库功能留给数据库本身。
有几种解决方法可以处理大型数据集。使用正确的数据类型并创建正确的索引将有很大帮助。
当您的数据库开始出现问题时，请搜索特定于您遇到的问题的内容。
大数据问题没有灵丹妙药。