我在每分钟需要存储1900+个加密货币的数据的情况下，我使用mysql innodb。
当前，表如下所示
coins_minute_id | coins_minute_coin_fk | coins_minute_usd | coins_minute_btc | coins_minute_datetime | coins_minute_timestamp
coins_minute_id = autoincrement id
coins_minute_coin_fk = medium int unsigned
coins_minute_usd = decimal 20,6
coins_minute_btc = decimal 20,8
coins_minute_datetime = datetime
coins_minute_timestamp = timestamp表在短时间内以惊人的速度增长，每分钟有1900多行被添加到表中。
这些数据将作为一个整体用于历史价格显示 D3.js 每种加密货币的折线图。
我的问题是如何优化这个数据库最好，我只想每5分钟收集一次数据，而不是每1分钟收集一次，但它仍然会在很短的时间内积累大量的数据，我还认为如果最好为每个加密货币创建一个唯一的表，你们中有谁喜欢设计数据库，知道其他一些非常聪明的方法来做这样的事情吗？
谨致问候
（来自评论）
SELECT coins_minute_coin_fk, coins_minute_usd
FROM coins_minutes
WHERE coins_minute_datetime >= DATE_ADD(NOW(),INTERVAL -1 DAY)
AND coins_minute_coin_fk <= 1000
ORDER BY coins_minute_coin_fk ASC
1条答案
按热度按时间z4iuyo4d1#
摆脱
coins_minute_前缀；它使sql混乱，没有提供任何有用的信息。不要指定两次时间——有一些简单的函数可以在它们之间进行转换
DATETIME以及TIMESTAMP. 为什么同时有“创建”和“更新”的时间戳？你在做UPDATE声明？如果是这样，那么代码就比简单的“插入”更复杂。您需要一个唯一的键来知道要更新哪一行。提供
SHOW CREATE TABLE; 你所提供的更具描述性。30次插入/秒很容易处理。300/秒可能有问题。
不要
PARTITION这张table没有什么真正的理由这么做。常见的有效原因是您希望定期删除“旧”数据。如果您在3个月后删除，我将用PARTITION BY RANGE(TO_DAYS(...))使用每周分区。更多讨论：http://mysql.rjweb.org/doc.php/partitionmaint向我们展示查询。如果不知道如何访问模式，就无法对其进行优化。
“批处理”插入比单行快得多
INSERT声明。这可以是INSERT INTO x (a,b) VALUES (1,2), (11,22), ...或者LOAD DATA INFILE. 后者是非常好的，如果你已经有一个csv文件。您的数据来自单一来源吗？或者1900个不同的来源？
mysql和mariadb对于您的任务可能是相同的(同样，需要查看查询。）pdo对这两种方法都适用；不需要重新编码。
在看到查询之后，我们可以讨论
PRIMARY KEY有什么次要的INDEX(es)拥有。1分钟对5分钟？你的意思是在后一种情况下你只会收集五分之一的行数吗？我们可以在其他细节公布之后再讨论这个问题。
这个问题在很多方面都没有意义。为什么停在“1000”呢？产量相当大；哪个客户关心那么多数据？排序是不确定的——不能保证datetime是有序的。为什么指定美元而不指定日期时间？请提供理由查询；那我可以帮你
INDEX(es).