数据库字段多少会影响速度吗

This topic created in 2638 days ago, the information mentioned may be changed or developed.

楼主是学生，不大懂。
服务器阿里云学生机。

用户表里存一堆用户信息，要求多个字段，这样检索会不会很慢。

还有几个问题:
类似用户发帖，是把所有用户发的帖子都放进一张表里吗。

用户的收藏字段，是不是按照一个字段存储多个文章 ID，违反第一范式的设计模式，有什么影响🤔。

如果要学习数据库相关设计，学习路线有哪些。

Supplement 1 · Mar 22, 2019

没想到有人还提到了我有没有资格考虑检索速度的问题。
我阐述一下我的观点，我原本以为数据库可能在一万条数据的时候就会变得卡顿，没想到这么强大。
因为没接触过，没看过其他人网站的数据库，所以才提的问题。
见识浅了，真不好意思。

字段

表里

用户

影响🤔

33 replies • 2019-03-23 08:48:37 +08:00

ecrazy

Mar 22, 2019 via iPhone

字段长度和个数都会有影响。去读官方 documents。

opengps

Mar 22, 2019

必然影响啊

bokchoys

Mar 22, 2019 via iPhone

几个问题可能很低端，但是对我很有帮助。
有没有论坛的数据库模型可以参考？

Mar 22, 2019

@bokchoys #3
你可以参考 discuz 的数据库设计，地址如下：
https://discuzt.cr180.com/discuzcode-db.html

simuhunluo

Mar 22, 2019 via Android

KV 表去存用户 ID 和收藏帖子 ID 吧。我觉得这样比较好

Mac

Mar 22, 2019 via Android

关键字:连表查询。虽然现在大数据并不提倡，但对于基础应用，还是很有用的。

Felldeadbird

Mar 22, 2019

有影响，但不至于说想象中那么可怕。
数据库设计我觉得更多是需要看现有的开源系统，其次是自己工作中实践总结。只有不断踩坑才知道影响的。
我司有一个 150 个字段的单表，只存放了 10W 数据，在日常的频繁查询（连表查询），并没有体会出多大的影响。我觉得在百万内的数据影响都是可以忽略的。只有千万，或者上亿才真正体会到时间的成本。

Solace202

Mar 22, 2019

我们有个表，500 个字段，100w+的数据量，不是特别明显。不过肯定有影响，但是肯定比数据量多少的影响小

bokchoys

Mar 22, 2019 via iPhone

@Felldeadbird #7 好的，谢谢

bokchoys

Mar 22, 2019 via iPhone

@ecrazy #1 行😂

bokchoys

Mar 22, 2019 via iPhone

@5G #4 好，谢谢

F281M6Dh8DXpD1g2

Mar 22, 2019

行存储数据库每次读取的时候都是读一行,所以一行要是太长的话肯定对性能有影响的

bokchoys

Mar 22, 2019 via iPhone

@Solace202 #8 用的是 mysql 还是其他？

zcmxw1

Mar 22, 2019

1.用户表里存一堆用户信息，要求多个字段，这样检索会不会很慢。
会慢，但是不会那么慢。添加合理的索引。几百万以内的数量级没啥问题。
2.类似用户发帖，是把所有用户发的帖子都放进一张表里吗。
还是，几百万数量级内，这样没问题。
3.用户的收藏字段
我觉得还是单独一张表吧。因为用户可能会收藏很多很多文章。一条数据包含 1 个用户,1 个文章。
4.如果要学习数据库相关设计，学习路线有哪些。
我没学过，我不清楚。。

bokchoys

Mar 22, 2019 via iPhone

@simuhunluo #5 KV 表是指什么？

bokchoys

Mar 22, 2019 via iPhone

@zcmxw1 #14 好的，十分感谢！

Mazexal

Mar 22, 2019

主要是对于磁盘 IO 不太好, 数据库是一条一条插入数据的, 一条数据大小和你字段多少是呈正相关的, 字段多的话两条数据之间间隔就大, 就需要更多资源去读取这条数据

bigdogbigpig

PRO

Mar 22, 2019

https://time.geekbang.org/column/intro/139

Solace202

Mar 22, 2019

@bokchoys postgreSQL

loading

Mar 22, 2019 via Android

必然影响，但是可忽略的。
不要啥都没整就关心太多的性能问题。

loading

Mar 22, 2019 via Android

等你真的遇到性能问题时，请个人优化就行，没访问量就不会有性能问题，有访问量就不缺钱了。

bokchoys

Mar 22, 2019 via iPhone

@loading #21 好的，谢谢

yaozmban2

Mar 22, 2019

@Mazexal 那是否可以从机算计组原理和操作系统原理出发这样作答？
数据要先读进内存，而内存和硬盘的 IO 是直接读取一个分页，分页的大小又是固定的，因此查相同的记录数，字段多的表需要交换的分页数就多，时间损耗就大。

zzzzzzZ

Mar 22, 2019

会，不过一般可以无视，表设计的时候注意一下即可
直接的解决方案了解一下“垂直分表”

在总的查询效率上字段数影响只占很小的一部分，只需要保证大数据字段尽可能少即可
决定查询效率大头的永远永远永远都是 SQL 的写法
其次才是索引、存储过程、读写分离、水平分表之类的数据库层面操作

大部分程序员写出来的 SQL 都有很高潜力的效率提升（数倍~数千倍的执行效率），只不过他们不知道而已，我目前开发的 SQL 也没有做到极致，这一门实践的少，只跟大神学过一些小技巧

mumbler

Mar 22, 2019

你的数据量还没资格考虑性能问题,大多数产品失败就因为在只有 100 用户的时候考虑一亿用户的情况而死掉的

bokchoys

Mar 22, 2019 via iPhone

@mumbler #25 谢谢指导。遇到了问题，只是想学习，谈不上有没有资格。

bokchoys

Mar 22, 2019 via iPhone

@zzzzzzZ #24 好的，感谢！

Mazexal

Mar 22, 2019

@yaozmban2 差不多吧, 你看看数据库底层存储模型就知道了

xbigfat

Mar 22, 2019

@bokchoys 他的意思是，数据量这个数量没有资格谈性能。。。确实要亿级的数据才会造成性能损失

lookatme

Mar 22, 2019

插入操作必然会慢，查询到话，走索引的话基本无差别，走全表查就凉凉了

ihavecat

Mar 22, 2019

会的，垂直分表就是一种解决这个的办法

zkeeper

Mar 23, 2019

楼上有几位同学说的好, 等真正有性能问题的时候再考虑性能其实也不晚.

但是有个很多人都会忽视的前提条件: 在初期设计的时候, 尽量做到各模块间低耦合性, 否则后期发现某个地方设计缺陷导致性能问题, 再想调整就麻烦了.

bokchoys

Mar 23, 2019 via iPhone

@zkeeper #32 谢谢指点