数据库
1.MyISAM引擎不支持事务和行级锁
2.MyISAM的特性
- 加锁与并发:MyISAM是对整张表加锁，而不是某一行。
- 读取时对需要读到的所有表加共享锁
- 写入时对表加排他锁
3.InnoDB（5.5版本后为默认引擎）
4.关系数据完整性
- 索引特性
- 实体完整性:主键属性不能为空值
- 参照完整性:外键为空或者等于对应的主键
- 用户自定义完整性
5.数据类型的优化
- 尽量使用可以正确存储数据的最小数据类型
- 尽量简单:使用内建类型而不是字符串来存储时间和日期；用整型存储IP地址
- 尽量避免NULL（如果计划在列上建索引，就应该避免NULL）
MySQL可以为整数类型指定宽度，如int（11），但是这个设置不会限制值的合法范围，只是限制了客户端的显示字符的个数
6.字句顺序：select ,from, where, group by, having, order by, limit
- where→between a and b (a≤x≤b)
8.blob和text都是为了存储很大的数据，blob采用二进制，text使用字符方式存储
- Memory引擎不支持BLOB和TEXT类型
- 有时候可以使用枚举列ENUM代替字符串
如:enum（apple，orange，fish），插进去是把每个值在列表中的位置保存，在.frm文件中保存着数字-字符串的映射表
ENUM是使用内部存储整数进行排序的，如果一开始字符串没有按字母排序，那么order by出来的不会是按字母顺序
- 日期与时间类型
- DATETIME能保存大范围的值:从1001到9999年，与时区无关，使用八个字节的存储空间
- TIMESTAMP只能保存小范围的值:从1970年到2038年，使用四个字节的存储空间，依赖时区
11.范式的优点和缺点
- 优点:
- 很少或者没有重复数据，冗余度低，只需要修改很少的数据
- 范式化的更新操作通常比反范式化要快
- 范式化表通常更小，可以更好放在内存里 执行操作更快
- 检索数据需要更少的DISTINCT或者GROUP BY语句
- 缺点:
- 需要更多的关联，这会使得索引策略无效
- 范式化会将本来一张表的列存放在不同的表 这些列在同一个表中本可以属于同一个索引
12.反范式化的优缺点
- 优点:
- 可以很好避免关联
- 当不需要关联的时候，即使是表没有使用索引而且是全表扫描，在数据比内存大的时候也会比关联快因为避免了随机I/O
- 缺点:
-
数据冗余，占用空间大
-
首先Mysql的基本存储结构是: 页(记录都存在页里边)，每个数据页都会为存储在它里边儿的记录生成一个页目录，在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录
-
加索引为什么可以让我们查询加快速度呢？
其实就是将无序的数据变成有序(相对)：一个没加主键的表，它的数据无序的放置在磁盘存储器上，一行一行的排列的很整齐， 跟我认知中的「表」很接近。如果给表上了主键，那么表在磁盘上的存储结构就由整齐排列的结构转变成了树状结构，也就是说的「平衡树」结构，换句话说，就是整个表就变成了一个索引。
整个表变成了一个索引，也就是所谓的「聚集索引」。 这就是为什么一个表只能有一个主键， 一个表只能有一个「聚集索引」，因为主键的作用就是把「表」的数据格式转换成「索引（平衡树）」的格式放置
索引能让数据库查询数据的速度上升， 而使写入数据的速度下降，原因很简单的， 因为平衡树这个结构必须一直维持在一个正确的状态， 增删改数据都会改变平衡树各节点中的索引数据内容，破坏树结构， 因此，在每次数据改变时， DBMS必须去重新梳理树（索引）的结构以确保它的正确，这会带来不小的性能开销。
每次给字段建一个新索引， 字段中的数据就会被复制一份出来， 用于生成索引。 因此， 给表添加索引，会增加表的体积， 占用磁盘存储空间。
- 非聚集索引和聚集索引的区别？
通过聚集索引可以查到需要查找的数据， 而通过非聚集索引可以查到记录对应的主键值 ， 再使用主键的值通过聚集索引查找到需要的数据
-
字段上加索引
-
表的主键、外键必须有索引；
-
数据量超过300的表应该有索引；
-
经常与其他表进行连接的表，在连接字段上应该建立索引；
-
经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；
-
索引应该建在选择性高的字段上；
-
索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；
-
复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替
-
频繁进行数据操作的表，不要建立太多的索引；
-
删除无用的索引，避免对执行计划造成负面影响；
17.索引种类
- B-Tree索引（一般默认为B-Tree索引）：一般用B树来存储数据，不同的底层的存储引擎使用不同的存储结构，InnoDB使用的是B+Tree树索引
- B-Tree能够加快数据的访问速度，因为存储引擎不用再全表扫描来获取需要的数据，而是从索引的根结点进行检索开始搜索
- 根结点中存放指向子节点的指针，通过比较节点页的值和要查找的值可以找到合适的指针来指向下层子节点
- 左边<key1; 右边≥key1
- 索引对多个值进行排序的依据是创建表的语句中定义索引时列的顺序
- B-Tree可以使用的查询类型
- 全值匹配：和和索引中的所有列进行匹配
- 匹配最左前缀：只使用索引的第一列
- 匹配列前缀：只匹配某一列的值的开头部分
- 匹配范围值
- 精确匹配某一列并范围匹配另外一列
- B-Tree索引的限制：
- 如果不是按照索引的最左列开始查找，则无法使用索引
- 不能跳过索引中的列
- 哈希索引（基于哈希表实现）
- 锁
- 表锁
- 开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低
- MyISAM和InnoDB都支持
- 分类：
- 表读锁
- 表写锁
-
读读不阻塞：当前用户在读数据（读），其他的用户也在读数据（读），不会加锁
-
读写阻塞：当前用户在读数据（读），其他的用户不能修改当前用户读的数据（写），会加锁！
-
写写阻塞：当前用户在修改数据（写），其他的用户不能修改当前用户正在修改的数据（写），会加锁！
-
行锁
-
开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高
-
InnoDB支持
-
InnoDB的行锁是基于索引的，只有通过索引条件检索数据才使用行级锁，否则，InnoDB将使用表锁
-
分类：
- 共享锁（S锁）：允许一个事务去读一行，阻止其他事务去获得相同的数据（排他锁）
- 共享锁也叫读锁，多个客户可以同时读取同一个资源，但是不允许其他客户修改
- 排他锁（X锁）：允许获得排他锁的事务去更新数据，但阻止其他事务去获得相同的数据（排他锁或共享锁）
- 排他锁也叫写锁，写锁会阻塞其他的写锁和读锁
扫一扫
3579
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
