作为开发 数据库很头疼吧
我们就以市场运用最广的mysql来说
其实基本的一些还好 增删改查 删就忘了吧
什么各种连 子查询 多表查询 其实都还好
当你遇到七八张表一起查的时候你就崩了。
好一点的一上午就写了两条sql语句 崩一点的一上午还没写出来
先说说写sql语句的感觉吧
千万别死记语法 就记感觉 而且sql这种东西只要你长期不用就忘干净了
可能只记得一个 select * from 了。 这是真的！！！ 这是所有做开发的噩梦！！！！
ORM 。。。。。万恶之源！！！
巨简单巨好用 典型的用时间换效率
什么 xxx.object.get
什么主外键一行解决 等等...
别做梦了！！！！ orm只适合 并发量不高的
mysql每秒并发量只有1100次
redis有11W次。
这也是非关系型数据库提出的根本原因
减少关系型数据库的访问量
数据库贵为整个项目的灵魂
但对初学者而言 一点都不友好！！！ 一大推命令要背
先说mysql引擎吧
主要就用两种
myisam 和 innodb吧
innodb好处是支持事物 这是最关键的一点 而且你可以rollback 也就是回滚
myisam是默认引擎
innodb的事物显得尤为重要 并发情况下你必须修改事物等级
事物是什么？
而且事物最大的特点用大白话来说就是 几个表一起操作 要么成功要么都失败
事物等级 就是在高并发的情况下每一条指令都是一个事物在其他事物执行结束后本事物在做什么
但是事物又分为四个等级
Serializable 串行化 一个任务一个任务的执行
这mysql本来并发就不行你还该成单并发
Repeatable read 可重复读 就是在其他事物还没有 保存之前 你就已经知道了
也称脏读 如果本事物已经读到了 你未提交的数据 但是你提交失败了
本事物又写到了数据库 这数据就是脏的
Read committed 读取已提交，其他事务提交了对数据的修改后，本事务就能读取到修改后的数据值
这个用的比较多
Read uncommitted 读取为提交，其他事务只要修改了数据，即使未提交，本事务也能看到修改后的数据值。
这是默认的 就是各自提交各自的
优化数据库
分硬件 软件 两种
硬件一般就是搭建mysql集群
主服务器只做 增删改
从服务器 作为查
想一下你账号密码天天改吗？天天注册新的账号吗？ 所以查询用的是最多的
而且一台服务器崩了无所谓呀~ 还有很多台服务器 因为数据是共享的
大白话就是 古代奴仆时代 主人天天干活很少 但是仆人干活很多
查询优化
这个你除了 使用缓存等等 其实最重要的还是查询语句
先说说索引 大白话来说吧
索引就是目录 你看新华字典时候是不是先看目录
你看电影时候是不是先找动作片等等
索引其实就是约束
primary key 主键
unique 唯一
default 默认
check 检查
foreign key 外键
一般常用的就这么多 我记得是有7个记得不了哈哈哈
索引虽然可以优化查询但是也会削弱增删改的速度
不过利大于弊 也没人天天注册修改 删除几乎更是不存在
而且很多时候你估计连改的权限都没有 只有查
索引的算法是B-tree 有想法的你自己搜一哈
好说说查询时注意的把
第一！ 这个 select * from table你就给我忘了吧
因为整表查询 在sql服务器中 撑不住两三次 你可以试试
说说普通查询吧 user_id
select * from table where id = user_id
这条没什么问题吧？ 有！！！
你在看看这条
select id from table where id = user_id
信我 虽然上面那一条没啥问题但是你老大看到你写下面这一条肯定更舒服
一个是整表查询 一个是字段查询能一样嘛！！！
还有几个需要避免
1 is null 疯了吧 这属于 整个表去遍历找为null的
2 <> != 别了吧 别用。。 和上面一样
1、2 这两条 如果你们公司并发很高 你又非要把这些数据取出来给领导看 你去问问运维 问问老大 每天凌晨什么点 访问量最低 去查
3 如果避免不了使用内连接查询也应当 使用limt 因为笛卡尔积太耗费资源了
虽然你拿到的数据不是笛卡尔积 但是这群数据是从 笛卡尔积过滤出来的
4 子查询 这个用的很多吧 一般主外键啊常用 但是！！ 子查询又分为两种
1 可独立 运行
2 不可独立运行
选可独立运行的
不可独立运行的 其实是有一个返回值 所以说能省还是省了吧
还有就是其实在很多时候写sql语句时候你会发现 有时候两条sql语句 比一条sql语句好写很多
相信我 如果你写两条！ 让你老大看见 你老大肯定会爆锤你！并发量本身就不高呀~
分组 记得配合聚合函数！！
内连接一般取相同左边链接是以作为主 右边以null填充 右链接是以右为主 左边以null填充
少用！ 逼不得已先考虑内连接
自关联 其实也是为了节省数据库资源 比较常见的是 省市区三级联动 商品分类系统
sql的执行顺序其实还是有说法的
先执行 from where group by ...最后是Limt 记得经常使用Limt
写得多了自然感受也就深了
我曾经为这样一道题为难过好久 简单一句话就是 千万级数据表如何分割
每张表最多存储1千万数据左右
如果超出该怎么办 是横向分割还是竖向分割
我专门请教了一位大神 因为我自己做的根本存不满
原话是
这叫 分表分库
如果只是分表的话可以拆表
比如 A存储 18年之前的数据 B存储18年之后的数据
这样来分
按照一个时间段吧表的数据分开
比如一个网站的订单表 存储用户好多年的订单数据
后台查询时候 有一个时间段选择 来查询 A 还是B
很多 银行 电商 他们的数据库都是这么设计的
最后在说说建表的三大范式吧
1 原子性 就是不可再分割 比如 sku
2 只描述一件事
3 表中不存在冗余字段
最后用ER图 关联
举个简单的例子 我们上班天天不是公交车就是地铁
就拿公交车举例
一张表
公交车 字段分为 那辆车 是否有空调 是否是快车 等等
另一张表存
乘客表 老年人 中年人 小孩 等等
最后一张表存
收费表 现金？ 老年卡 学生卡 普通卡 等等
最后商量字段 主外键等等
总而言之 数据库的命令 永远不要记格式
只记感觉 敲多了 一点都不难
迎难而上 你才会进步
如果你作为一个后端想做大项目
一定sql要写的6 因为他们不会用ORM
