MySQL最佳SQL优化实践手册 - CSDN文库

4星 · 超过85%的资源需积分: 19 37 浏览量更新于2023-03-16 评论 2 收藏 934KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

资源由 www.eimhe.com 美河学习在线收集分享

表的优化：

1：定长与变长分离：如 id int 占 4 个字节，char(4)占 4 个字符长度，也是定长==》即每一

单元值占的字节是固定的，查询非常快，这个放在一张表里

而 varchar，textblob 这样的变长字段，适合单放一张表，也就是放在附属表里，用主键和核

心表关联起来

2：常用字段和不常用字段要分离

例如：个人中心里的简介什么的不常用，就单独放个表，而每天都要查询到的数据放到

一张表

3：在 1 对多，需要关联同级的字段上，添加冗余字段

列选择原则：

1：字段类型优先级：整型>date,time>enum,char>varchar>blob,text

列的特点分析：

整型：定长，没有国家、地区之分，没有字符集的差异

比如：timyint 1,2,3,4,5 《==》 char(1) a,b,c,d 他们两个比：重空间上看，都占 1

个字节，但是 order by 排序的话，前者快，原因：后者需要考虑字符集与校对集（就

是排序规则）

Time 定长，运算快，节省空间，优先用时间戳来存整型，但是如果考虑时区的话写 sql

时不方便例如： where>”2015-10-12”

Enum:定长，能起到约束值的目的。

Char 定长但是需要考虑字符集和（排序）校对集

Varchar 不定长要考虑字符集的转换与排序时的校对集，速度慢

Text blob 无法使用内存临时表（如果要排序的话，只能拿到磁盘上进行操作，会更慢）

2：够用就行，不要慷慨：原因==》大的字段浪费内存，影响速度

以年龄威力 timyint unsigned not null ,可以存储 255 岁，足够了，但是用 int 浪费 3

个字节

以 varchar（10），varchar（300）存储的内容相同，但在表联查时，varchar（300）

要花费更多的内存

3：尽量避免用 NULL()

原因：NULL 不利于索引，要用特殊的字节来标注

在磁盘上占据的空间其实更大，虽然 mysql5.5 已经对 null 做了优化，但效果不明

显

索引优化策略

1：索引类型==》btree 索引、hash 索引

1.1 B-tree 索引

剩余12页未读，继续阅读

评论1

kobe610968189

2017-12-26

资源还可以，但是一般还行

jiangsucsdn001

粉丝: 47
资源: 231

会员权益专享

图片转文字

全年可省5，000元立即开通

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈