关于高频读写 mysql 数据库的设计

当天 30 万的数据用内存，隔天(半天、小时)入库

@netnr 我要实时查询的

一台机器，8g 内存，要部署 kafka，mysql，web 应用

每秒 4 条，写入压力并不大，但是大量读取，你得用从库了

缓存解决，把最新数据留在内存里，查询时候不用去硬盘

写库 30 万条还算可以，关键是查询压力如何？查询跨度如何？得说明白才好分析。

内存表。

@kop1989 做了分表处理，主表基本会保持在 2000w 左右的数据，查询是跨 3 到 4 张表

一次拿多条，一条语句插完全没有问题，查询看你是索引还是文本，查的量有多少，我建议写多一份 redis 或者是 LSM Tree 的数据库。kafka 的数据等 mysql 落库再删。

@lhx2008 数据还有各种查询条件，还要做到实时展示，不好弄 redis

每秒 4 条并不算高，看过查询计划哪一步比较慢吗？理论上并不会慢，调个参数试试？

查询慢 explain 看看结果？
确定查询满是因为写导致的吗？

每天 30 万真的不多。
阿里云最便宜的 rds，也可以支持每天 30 万订单（订单明细，日志等加起来肯定不止 30 万）。

@encro 大部分的 sql 都看过了，都走了索引，把写停掉就能快不少

读写分离

@wsldl123292
写是无序的（ innodb 主键不连续）导致索引重建或者锁表？

1，开启慢日志吧；
2，然后 show full processlist，看处于什么状态。

30 万不大吧，配置确实有点低

每秒 4 条插入，不是常规理解的“高频写”

@encro 应该是，主键是 uuid

@wsldl123292
主键不能是 UUID，会导致索引重排（除非你 UUID 是递增的参考另外一个帖子使用 SnowFlake ）

这个配置，每天 30w，如果你不是一次读这么多的话应该足以

有硬件限制 不建议搞什么主从了 可以做一些索引的优化

就像 @encro 提到的用 snowflake （ int64 ） 做主键 不要用 string

@wangyzj 就是每次读一天的，当然是分页

我有台 1H2G 的机器也想这么做。。。

内存临时存储数据，宕机时，内存数据如何挽救？

让你客户去屎吧

@wsldl123292 spa 全读出来然后前端分页？

读取的是啥内容？

分表，因为更新的时候，会加锁限制读到脏数据，分表可以避免不相关的加锁，同时索引更新会更快。或者你允许客户脏读。