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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› MySQL 5.5 Community Server

› MySQL 5.6 Community Server

› Percona Configuration Wizard

› XtraBackup 搭建主从复制

Great Sites on MySQL

› Percona

› MySQL Performance Blog

› Severalnines

推荐管理工具

› Sequel Pro

› phpMyAdmin

推荐书目

› MySQL Cookbook

MySQL 相关项目

› MariaDB

› Drizzle

参考文档

› http://mysql-python.sourceforge.net/MySQLdb.html

这是一个创建于 1780 天前的主题，其中的信息可能已经有所发展或是发生改变。

有一个需求，是从 kafka 读取数据入 mysql，数据要保证实时性，要及时入库和查询，现在是的数据量大概每天 30 万，基本是每秒 4 条的频率现在的问题是在写入的同时再去查库，会导致查询变慢，有什么好的方案吗？

由于硬件限制，只有台 8g 的机器，没有办法分布式多节点

第 1 条附言 · 2019-12-31 13:31:43 +08:00

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

第 2 条附言 · 2019-12-31 13:32:22 +08:00

机器加不了，客户要求，没办法

MySQL

Kafka

实时性

查询

29 条回复 • 2019-12-31 18:25:05 +08:00

netnr

2019-12-31 13:10:19 +08:00

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

wsldl123292

2019-12-31 13:15:29 +08:00

@netnr 我要实时查询的

wsldl123292

2019-12-31 13:15:52 +08:00

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

opengps

2019-12-31 13:16:22 +08:00

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

opengps

2019-12-31 13:16:54 +08:00

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

kop1989

2019-12-31 13:18:30 +08:00

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

widdy

2019-12-31 13:22:05 +08:00

内存表。

wsldl123292

2019-12-31 13:24:13 +08:00

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

lhx2008

2019-12-31 13:25:45 +08:00 via Android

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

wsldl123292

2019-12-31 13:31:32 +08:00

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

optional

2019-12-31 13:33:51 +08:00

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

encro

2019-12-31 13:36:10 +08:00

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

encro

2019-12-31 13:37:56 +08:00

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

wsldl123292

2019-12-31 13:38:08 +08:00

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

p23XnFNH1Wq953rV

2019-12-31 13:40:11 +08:00

读写分离

encro

2019-12-31 13:43:03 +08:00

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

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

authony2020

2019-12-31 13:51:39 +08:00

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

sudoz

2019-12-31 13:52:49 +08:00

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

wsldl123292

2019-12-31 14:02:30 +08:00

@encro 应该是，主键是 uuid

encro

2019-12-31 14:08:53 +08:00

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

wangyzj

2019-12-31 14:20:33 +08:00

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

zunceng

2019-12-31 14:30:25 +08:00

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

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

wsldl123292

2019-12-31 14:30:49 +08:00

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

fancy111

2019-12-31 14:57:09 +08:00

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

aloyuu

2019-12-31 15:11:57 +08:00 via Android

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

wysnylc

2019-12-31 16:02:48 +08:00

让你客户去屎吧

wangyzj

2019-12-31 16:19:29 +08:00

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

luozic

2019-12-31 16:47:07 +08:00

读取的是啥内容？

jimrok

2019-12-31 18:25:05 +08:00

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