MySQL复习——项目基础使用

Posted 2021-07-27 胖虎是只mao

主键一般不用业务数据

1. 数据库优化：

①空间换时间：在一张表中牺牲一个字段的空间，用来储存一个字段值，减少一次查询；换取时间。因为，以后的存储的成本会越来越小于时间的成本
② join 联合查询
③ 图片url地址 存json类型

实例优化：

1. 图片url地址 存json类型

2. 多级评论，用一张表可以搞定，添加parent_id 字段。二级评论的parent_id等于一级评论的comm_id
   

三. mysql 外键

在实际业务中，有无外键其实都可行。只是用来update/delete主表的时候，能找到从表之中是否有对应额外的数据，从而维护主表和从表的一致性。在数据量大的时候，对于性能要求更高的时候，需要删除 外键，因为外键也会给mysql 带来额外的开销。那如何维护主表和从表之间的一致性呢？ 自己写代码维护，而不需要mysql 去维护了

四.索引

加入索引，提升查询速度
从之前的一行一行比对，变成可以直接定位所查询的位置，用到的方法是用一种树形结构 。B+ Tree等，目的是缩小查找范围
因为使用索引后可以不用扫描全表来定位某行的数据，而是先通过索引表找到该行数据对应的物理地址然后访问相应的数据

select * from user where mobile=‘xxxxx`’ and 1=1 数据计算 另外的数据类型（数据结构 Tree）

索引使用场景：某个字段经常进行查询筛选（常放到where条件后面进行过滤筛选的）

1、索引的优缺点

优势：可以快速检索，减少I/O次数，加快检索速度；根据索引分组和排序，可以加快分组和排序；

劣势：索引本身也是表，因此会占用存储空间，一般来说，索引表占用的空间的数据表的1.5倍；索引表的维护和创建需要时间成本，这个成本随着数据量增大而增大；构建索引会降低数据表的修改操作（删除，添加，修改）的效率，因为在修改数据表的同时还需要修改索引表；

2、索引的实现原理
MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，B+Tree索引，哈希索引，全文索引等等
原理具体看

五. MySQL数据库引擎

一般常用两种 InnoDB存储引擎和 MyISAM存储引擎。一般默认 InnoDB存储引擎

两者最大的区别是 InnoDB存储引擎 支持事务，外键完整性约束
可以针对 不同的表 选择不同的数据库引擎

如图中文章内容表，不常变动，只有新增和查询，而且是大文件

db.session 是SQLAlchemy在每个事务中用来记录数据库操作的对象

六、SQLAlchemy基础操作

filter_by 和filter区别：
filter_by 适用于等值查询、and合并查询，只有一个等号。filter适用于 等值或者大小于、不等于 、or都可，是双等号

复合查询
User.query.filter(User.name.startswith(‘13’)).order_by(User.id.desc()).offset(2).limit(5).all()

query = User.query.filter(User.name.startswith('13'))
query = query.order_by(User.id.desc())
query = query.offset(2).limit(5)
ret = query.all()

优化查询

user = User.query.filter_by(id=1).first()  # 查询所有字段
select user_id, mobile......

select * from   # 程序不要使用
select user_id, mobile,.... # 查询指定字段

from sqlalchemy.orm import load_only
User.query.options(load_only(User.name, User.mobile)).filter_by(id=1).first() # 查询特定字段

聚合查询

最后生成的是一个列表中有各个元组

from sqlalchemy import func

db.session.query(Relation.user_id, func.count(Relation.target_user_id)).filter(Relation.relation == Relation.RELATION.FOLLOW).group_by(Relation.user_id).all()

SQLAlchemy数据库详细

七、数据库索引原理

未加索引之前，查询，是一行一行进行遍历。加上索引之后，查询，基于二叉树的结构，每次左边的叶子节点比右边叶子结点的值要小，方便查询

缺点：
建立索引之后，会增加增删改的时间
原因： 与维护有关
为了保证查询速度，应该尽量保证左右叶子节点平衡（数量）。不能一方过于失衡，如果一方失衡，会导致根节点的变化（不再是34），导致这棵树会重新调整，增加维护成本。所以，加索引，利于查询，不利于增加删除修改

八、SQL查询优化（项目考点）

• 避免全表扫描，应考虑在 where 及 order by 涉及的列上建立索引；

• 查询时使用select明确指明所要查询的字段，避免使用select *的操作；

• SQL语句尽量大写，如：

 SELECT name FROM t WHERE id=1

对于小写的sql语句，通常数据库在解析sql语句时，通常会先转换成大写再执行。

• 尽量避免在 where 子句中使用!=或<>操作符， MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE；

  SELECT id FROM t WHERE name LIKE ‘abc%’

• 对于模糊查询，如：

模糊查询会使查询效率变低

 SELECT id FROM t WHERE name LIKE ‘%abc%’

或者

  SELECT id FROM t WHERE name LIKE ‘%abc’

将导致全表扫描，应避免使用，若要提高效率，可以考虑全文检索；

• 遵循最左原则，在where子句中写查询条件时把索引字段放在前面，如:

  mobile为索引字段，name为非索引字段
  推荐
  SELECT ... FROM t WHERE mobile='13911111111' AND name='python'
  不推荐
  SELECT ... FROM t WHERE name='python' AND mobile='13911111111' 

  建立了复合索引 key(a, b, c)
  推荐
  SELECT ... FROM t WHERE a=... AND b=... AND c= ...
  SELECT ... FROM t WHERE a=... AND b=...
  SELECT ... FROM t WHERE a=...
  不推荐 (字段出现顺序不符合索引建立的顺序)
  SELECT ... FROM t WHERE b=... AND c=...
  SELECT ... FROM t WHERE b=... AND a=... AND c=...
  ...

• 能使用关联查询解决的尽量不要使用子查询，如:

 子查询
  SELECT article_id, title FROM t_article WHERE user_id IN (SELECT user_id FROM t_user  WHERE user_name IN ('itcast', 'itheima', 'python'))

  关联查询(推荐)
  SELECT b.article_id, b.title From t_user AS a INNER JOIN t_article AS b ON a.user_id=b.user_id WHERE a.user_name IN ('itcast', 'itheima', 'python');

能不使用关联查询的尽量不要使用关联查询；

• 不需要获取全表数据的时候，不要查询全表数据，使用LIMIT来限制数据。

九、数据库优化（项目考点）

• 在进行表设计时，可适度增加冗余字段(反范式设计)（空间换时间），减少JOIN操作；
• 多字段表可以进行垂直分表优化，多数据表可以进行水平分表优化；
• 选择恰当的数据类型，如整型的选择；
• 对于强调快速读取的操作，可以考虑使用MyISAM数据库引擎；
• 对较频繁的作为查询条件的字段创建索引；唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件；更新非常频繁的字段不适合创建索引；
• 编写SQL时使用上面的方式对SQL语句进行优化；
• 使用慢查询工具找出效率低下的SQL语句进行优化；
• 构建缓存，减少数据库磁盘操作；
• 可以考虑结合使用内在型数据库，如Redis，进行混合存储。