这是一个创建于 1803 天前的主题，其中的信息可能已经有所发展或是发生改变。
以背单词软件为例，如果是在传统的关系型数据库比如 MySQL 里，一个名为 notes 表存储用户的笔记，那这个表里有一个 user_id 字段，并以这个字段建立 BTree 索引的话吧？尽管这里使用了 BTree 索引，性能上还是会有不必要的开销？
那关系型数据库能不能干脆为每个用户建立一个表？表名是 notes_${user_id} ，相当于一个用户的所有笔记单独成一个文件这样去管理。。
应该是有专门针对这种特征的数据存储的数据库的吧？谢谢指点。
那关系型数据库能不能干脆为每个用户建立一个表？表名是 notes_${user_id} ，相当于一个用户的所有笔记单独成一个文件这样去管理。。
应该是有专门针对这种特征的数据存储的数据库的吧？谢谢指点。
 | 1 Light3 2021 年 5 月 12 日 亲 都 2021 年了 你不知道 非关系型数据库吗 |
| 3 Light3 2021 年 5 月 12 日 关于用户数据 完全可以使用 MongoDB 然后将用户记录组装成一个 json 格式来存储 用户登录时 将 json 取出 存放于 Redis 来加快操作 操作完 事实更新 并同步存储 至于你所嘲讽的 用 redis 做一个 请问 json 你不会写吗? 还是? |
 | 4 Kilerd 2021 年 5 月 12 日  1 分库分表，常规配置了。如果就这么做的话，就叫 Paas 平台了，俗称分租户。 |
 | 5 loginbygoogle 2021 年 5 月 12 日 2 过度设计 |
 | 6 Newyorkcity OP @Light3 换到记账软件一个用户可能产生近千条条目你也用 redis 里的哈希表？亲 都 2021 年了 会有人不知道非关系型数据库？ |
 | 7 supermoonie 2021 年 5 月 12 日 via iPhone 1 当时做记账的时候用的 hbase |
 | 8 ch2 2021 年 5 月 12 日 1 放到一个表里是没问题的，底层索引一个用户的数据都是放一块的 你没有必要逻辑上自行做这种事 |
 | 9 3dwelcome 2021 年 5 月 12 日 楼主你也太小看 B 树索引后的查找速度了，一个用户几千条毛毛雨，绝不可能翻车的。 |
 | 10 yungo8 2021 年 5 月 12 日 via Android 结合 8 楼的，我感觉如果用户数也不是那么多的话，可以给用户编号 1...1000000，使用一张表来维护然后每 5w 用户对应用一张表是否可行？ 另外，网上看到的笔记这种数据，应该存文档型数据库比较好。 |
 | 11 des 2021 年 5 月 12 日 via iPhone 我实在没搞懂你的纠结点在哪里 btree 索引耗性能？你这个表也到不了一天千万的写入吧？ 再有存一千条 hash 到 redis，又不是什么大问题，存用户 id 到 note id 的映射就完了 |
| 12 Newyorkcity OP @des 对 MySQL 的性能了解不深所以有所担忧 |
Select Language