谈谈mysql相关知识点
第一:SQL分类与SQL语句
数据定义语言:DDL,用来定义数据库对象:数据库,表,列等。关键字:create,alter,drop等
数据操作语言:DML,用来对数据库中表的记录进行更新。关键字:insert,delete,update等
数据控制语言:DCL,用来定义数据库的访问权限和安全级别,及创建用户;关键字:grant等
数据查询语言:DQL,用来查询数据库中表的记录。关键字:select,from,where等
常用的字段类型:
数字型:int
浮点型:double
字符型:varchar(可变长字符串)
日期类型:date(只有年月日,没有时分秒)
datetime(年月日,时分秒)
boolean类型:不支持
分类 |
类型名称 |
说明 |
整数类型 |
tinyInt |
很小的整数 |
smallint |
小的整数 |
|
mediumint |
中等大小的整数 |
|
int(integer) |
普通大小的整数 |
|
小数类型 |
float |
单精度浮点数 |
double |
双精度浮点数 |
|
decimal(m,d) |
压缩严格的定点数------开发时用 |
|
日期类型 |
year |
YYYY 1901~2155 |
time |
HH:MM:SS -838:59:59~838:59:59 |
|
date |
YYYY-MM-DD 1000-01-01~9999-12-3 |
|
datetime-开发用 |
YYYY-MM-DD HH:MM:SS 1000-01-01 00:00:00~ 9999-12-31 23:59:59 |
|
timestamp |
YYYY-MM-DD HH:MM:SS 1970~01~01 00:00:01 UTC~2038-01-19 03:14:07UTC |
|
文本、二进制类型 |
CHAR(M) |
M为0~255之间的整数 |
VARCHAR(M) |
M为0~65535之间的整数 |
|
TINYBLOB |
允许长度0~255字节 |
|
BLOB |
允许长度0~65535字节 |
|
MEDIUMBLOB |
允许长度0~167772150字节 |
|
LONGBLOB |
允许长度0~4294967295字节 |
|
TINYTEXT |
允许长度0~255字节 |
|
TEXT |
允许长度0~65535字节 |
|
MEDIUMTEXT |
允许长度0~167772150字节 |
|
LONGTEXT |
允许长度0~4294967295字节 |
|
VARBINARY(M) |
允许长度0~M个字节的变长字节字符串 |
|
BINARY(M) |
允许长度0~M个字节的定长字节字符串 |
单表约束:
* 主键约束:primary key
* 唯一约束:unique
* 非空约束:not null
* 注意:主键约束 = 唯一约束 + 非空约束
查看数据库中的所有表:show tables;
查看表结构:desc 表名;
值如果是字符串或者日期需要加引号’’ (一般是单引号)
面试题:
删除表中所有记录使用delete from 表名; 还是用truncate table 表名;
删除方式:delete 一条一条删除,不清空auto_increment记录数。
truncate 直接将表删除,重新建表,auto_increment将置为零,从新开始。
CMD中文乱码:修改my.ini文件,然后重启mysql服务器
聚合函数(组函数)
特点:只对单列进行操作
常用的聚合函数:
-
- sum():求某一列的和
- avg():求某一列的平均值
- max():求某一列的最大值
- min():求某一列的最小值
- count():求某一列的元素个数
关于groupby 和having
- select语句中的列(非聚合函数列),必须出现在group by子句中
- group by子句中的列,不一定要出现在select语句中
- 聚合函数只能出现select语句中或者having语句中,一定不能出现在where语句中。
union 集合的并集(不包含重复记录)
unionall集合的并集(包含重复记录)
MySQL查询语法顺序
- SELECT
- FROM
- LEFT JOIN
- ON
- WHERE
- GROUP BY
- HAVING
- ORDER BY
- LIMIT
WHERE条件执行顺序(影响性能)
- MYSQL:从左往右去执行WHERE条件的。
- Oracle:从右往左去执行WHERE条件的。
结论:写WHERE条件的时候,优先级高的部分要去编写过滤力度最大的条件语句
JOIN 按照功能大致分为如下三类:
- CROSS JOIN(交叉连接):笛卡尔积连接(X*Y),交叉连接的表现:行数相乘、列数相加
隐式交叉连接:select * from A,B;
显式交叉连接:SELECT * FROM A CROSS JOIN B
- INNER JOIN(内连接或等值连接):内连接也叫等值连接,内联接使用比较运算符根据每个表共有的列的值匹配两个表中的行
隐式内连接:SELECT * FROM A,B WHERE A.id = B.id
显式内连接:SELECT * FROM A INNER JOIN B ON A.id = B.id
- OUTER JOIN(外连接):左外连接、右外连接、全外连接(MySQL不支持)
外连接总结:
- 通过业务需求,分析主从表
- 如果使用LEFT JOIN,则主表在它左边
- 如果使用RIGHT JOIN,则主表在它右边
- 查询结果以主表为主,从表记录匹配不到,则补null
分页查询:
MySQL的分页关键字是:LIMIT
LIMIT关键字不是SQL92标准提出的关键字,它是MySQL独有的语法。
通过Limit关键字,MySQL实现了物理分页。
分页分为逻辑分页和物理分页
逻辑分页:将数据库中的数据查询到内存之后再进行分页。
物理分页:通过LIMIT关键字,直接在数据库中进行分页,最终返回的数据,只是分页后的数据。
第二:MySql架构
逻辑架构图:
Connectors:指的是不同语言中与SQL的交互
Management Serveices & Utilities:系统管理和控制工具
Connection Pool: 连接池:
*管理缓冲用户连接,线程处理等需要缓存的需求。
* 负责监听对 MySQL Server 的各种请求,接收连接请求,转发所有连接请求到线程管理模块。每一个连接上 MySQL Server 的客户端请求都会被分配(或创建)一个连接线程为其单独服务。
* 而连接线程的主要工作就是负责 MySQL Server 与客户端的通信,接受客户端的命令请求,传递 Server 端的结果信息等。线程管理模块则负责管理维护这些连接线程。包括线程的创建,线程的 cache 等
SQL Interface: SQL接口:接受用户的SQL命令,并且返回用户需要查询的结果。比如select from就是调用SQL Interface
Parser: 解析器:
* SQL命令传递到解析器的时候会被解析器验证和解析。
主要功能:
a . 将SQL语句进行语义和语法的分析,分解成数据结构,然后按照不同的操作类型进行分类,然后做出针对性的转发到后续步骤,以后SQL语句的传递和处理就是基于这个结构的。
b. 如果在分解构成中遇到错误,那么就说明这个sql语句是不合理的
Optimizer: 查询优化器:
* SQL语句在查询之前会使用查询优化器对查询进行优化。
* 它使用的是“选取-投影-联接”策略进行查询。
用一个例子就可以理解: select uid,name from user where gender = 1;
* 这个select 查询先根据where 语句进行选取,而不是先将表全部查询出来以后再进行过滤
* 这个select查询先根据uid和name进行属性投影,而不是将属性全部取出以后再进行过滤
* 将这两个查询条件联接起来生成最终查询结果
Cache和Buffer: 查询缓存:
他的主要功能是将客户端提交给MySQL的 select请求的返回结果集 cache 到内存中,与该 query 的一个 hash 值 做一个对应。该 Query 所取数据的基表发生任何数据的变化之后, MySQL 会自动使该 query 的Cache 失效。在读写比例非常高的应用系统中, Query Cache 对性能的提高是非常显著的。当然它对内存的消耗也是非常大的。
如果查询缓存有命中的查询结果,查询语句就可以直接去查询缓存中取数据。这个缓存机制是由一系列小缓存组成的。比如表缓存,记录缓存,key缓存,权限缓存等
存储引擎接口:
存储引擎接口模块可以说是 MySQL 数据库中最有特色的一点了。目前各种数据库产品中,基本上只有 MySQL 可以实现其底层数据存储引擎的插件式管理。这个模块实际上只是 一个抽象类,但正是因为它成功地将各种数据处理高度抽象化,才成就了今天 MySQL 可插拔存储引擎的特色。
从图还可以看出,MySQL区别于其他数据库的最重要的特点就是其插件式的表存储引擎。MySQL插件式的存储引擎架构提供了一系列标准的管理和服务支持,这些标准与存储引擎本身无关,可能是每个数据库系统本身都必需的,如SQL分析器和优化器等,而存储引擎是底层物理结构的实现,每个存储引擎开发者都可以按照自己的意愿来进行开发。
注意:存储引擎是基于表的,而不是数据库。
* MySQL 5.5之后,默认的存储引擎由MyISAM变为InnoDB。
* 多存储引擎是mysql有别于其他数据库的一大特性;
* 存储引擎是针对表的
|
Innodb |
Myisam |
存储文件 |
.frm 表定义文件 .ibd 数据文件 |
.frm 表定义文件 .myd 数据文件 .myi 索引文件 |
锁 |
表锁、行锁 |
表锁 |
事务 |
ACID |
不支持 |
CRDU |
读、写 |
读多 |
count |
扫表 |
专门存储的地方 |
索引结构 |
B+ Tree |
B+ Tree |
MySQL是通过文件系统对数据进行存储和管理的。
MySQL从物理结构上可以分为日志文件和数据文件。
MySQL通过日志记录了数据库操作信息和错误信息。常用的日志文件包括
错误日志(默认是开启的,而且从5.5.7以后无法关闭错误日志)、
二进制日志(默认是开启的,而且从5.5.7以后无法关闭错误日志,可以用于数据恢复以及主从复制)、
查询日志(默认情况下通用查询日志是关闭的,建议不开启)、
慢查询日志(默认是关闭的。需要通过设置:slow_query_log=ON进行开启。)
InnoDB 引擎在线 Redo 日志(事务日志(InnoDB特有的日志)也叫redo日志)、中继日志(是在主从复制环境中产生的日志。主要作用是为了从机可以从中继日志中获取到主机同步过来的SQL语句,然后执行到从机中)等。
查看MySQL数据文件:SHOW VARIABLES LIKE ‘%datadir%’;
- .frm文件:主要存放与表相关的数据信息,主要包括表结构的定义信息
- .ibd和.ibdata文件:用来存储InnoDB存储引擎的表数据和索引信息
- .myd文件:主要用来存储使用MyISAM存储引擎的表数据信息。
- .myi文件:主要用来存储使用MyISAM存储引擎的表数据文件中任何索引的数据树。
第三:MySql索引
* 使用索引的主要目的是为了优化查询速度
* 索引是一种特殊的文件或者叫数据结构(InnoDB数据表上的索引是表空间的一个组成部分),它们包含着对数据表里所有记录的引用指针。更通俗的说,数据库索引好比是一本书前面的目录,能加快数据库的查询速度。
索引是在存储引擎中实现的,也就是说不同的存储引擎,会使用不同的索引:MyISAM和InnoDB存储引擎:只支持BTREE索引, 也就是说默认使用BTREE,不能够更换 * MEMORY/HEAP存储引擎:支持HASH和BTREE索引
索引的分类:
* 单列索引:
* 普通索引:MySQL中基本索引类型,没有什么限制,允许在定义索引的列中插入重复值和空值,纯粹为了查询数据更快一点。
* 唯一索引:索引列中的值必须是唯一的,但是允许为空值,
* 主键索引:是一种特殊的唯一索引,不允许有空值。
* 组合索引
* 在表中的多个字段组合上创建的索引,只有在查询条件中使用了这些字段的左边字段时,索引才会被使用,使用组合索引时遵循最左前缀集合。
* 全文索引
* 全文索引,只有在MyISAM引擎上才能使用,只能在CHAR,VARCHAR,TEXT类型字段上使用全文索引。
* 空间索引:不做介绍,一般使用不到。
B Tree和B+ Tree的特点与区别
* 树的高度一般都是在2-4这个高度,树的高度直接影响IO读写的次数。
* 如果是三层树结构---支撑的数据可以达到20G,如果是四层树结构---支撑的数据可以达到几十T
* B Tree和B+ Tree的最大区别在于非叶子节点是否存储数据的问题。B Tree是非叶子节点和叶子节点都会存储数据。而B+ Tree只有叶子节点才会存储数据,而且存储的数据都是在一行上,而且这些数据都是有指针指向的,也就是由顺序的。
非聚集索引
* 叶子节点只会存储数据行的指针,简单来说数据和索引不在一起,就是非聚集索引。
* 主键索引和辅助索引都会存储指针的值
聚集索引(InnoDB)
* 主键索引(聚集索引)的叶子节点会存储数据行,也就是说数据和索引是在一起,这就是聚集索引。
* 辅助索引只会存储主键值
* 如果没有没有主键,则使用唯一索引建立聚集索引;如果没有唯一索引,MySQL会按照一定规则创建聚集索引。
使用索引的注意事项
- 尽量创建组合索引(组合索引其实会默认按照最左前缀原则帮我们创建多组索引,组合索引(id,name,sex)
- 索引最左前缀原则
- 索引覆盖:要查询的列,也要使用索引覆盖住
第四:MySql性能优化
1:查看执行计划explain
它可以对 SELECT 语句进行分析, 并输出 SELECT 执行的详细信息, 以供开发人员针对性优化.
explain出来的信息有10列,分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra,下面对这些字段进行解释:
- id: SELECT 查询的标识符. 每个 SELECT 都会自动分配一个唯一的标识符.
- select_type: SELECT 查询的类型.
- table: 查询的是哪个表
- partitions: 匹配的分区
- type: join 类型
- possible_keys: 此次查询中可能选用的索引
- key: 此次查询中确切使用到的索引.
- ref: 哪个字段或常数与 key 一起被使用
- rows: 显示此查询一共扫描了多少行. 这个是一个估计值.
- filtered: 表示此查询条件所过滤的数据的百分比
- extra: 额外的信息
2:慢查询(需要开启慢查询功能,默认关闭)
数据库查询快慢是影响项目性能的一大因素,对于数据库,我们除了要优化 SQL,更重要的是得先找到需要优化的 SQL。
MySQL 数据库有一个“慢查询日志”功能,用来记录查询时间超过某个设定值的SQL,这将极大程度帮助我们快速定位到症结所在,以便对症下药。
分析慢查询日志:MySQL自带的mysqldumpslow
常用参数说明:
- -s:是表示按照何种方式排序
- -t:是top n的意思,即为返回前面多少条的数据
- -g:后边可以写一个正则匹配模式,大小写不敏感的
得到按照时间排序的前10条里面含有左连接的查询语句。
mysqldumpslow -s t -t 10 -g “left join” /var/lib/mysql/localhost_slow.log
使用percona-toolkit工具分析慢查询
3:性能分析语句show profile
Query Profiler是MYSQL自带的一种query诊断分析工具,通过它可以分析出一条SQL语句的性能瓶颈在什么地方。
通常我们是使用的explain,以及slow query log都无法做到精确分析,但是Query Profiler却可以定位出一条SQL语句执行的各种资源消耗情况,比如CPU,IO等,以及该SQL执行所耗费的时间等。不过该工具只有在MYSQL 5.0.37以及以上版本中才有实现。
默认的情况下,MYSQL的该功能没有打开,需要自己手动启动。
show profiles :以列表形式显示最近发送到服务器上执行的语句的资源使用情况.显示的记录数由变量:profiling_history_size 控制,默认15条
查询优化建议点:
第五:MySql事务处理
- 在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。
- 事务处理可以用来维护数据库的完整性,保证成批的 SQL 语句要么全部执行,要么全部不执行。
- 事务用来管理DDL、DML、DCL操作,比如 insert,update,delete 语句
ACID:
- 原子性:构成事务的的所有操作必须是一个逻辑单元,要么全部执行,要么全部不执行。
- 稳定性(一致性):数据库在事务执行前后状态都必须是稳定的。
- 隔离性:事务之间不会相互影响。
- 可靠性(持久性):事务执行成功后必须全部写入磁盘。
在 MySQL 命令行的默认设置下,事务都是自动提交的,即执行 SQL 语句后就会马上执行 COMMIT 操作。因此要显式地开启一个事务务须使用命令 BEGIN 或 START TRANSACTION,或者执行命令 SET AUTOCOMMIT=0,用来禁止使用当前会话的自动提交。
在事务的并发操作中可能会出现一些问题:
- 脏读:一个事务读取到另一个事务未提交的数据。
- 不可重复读:一个事务因读取到另一个事务已提交的数据。导致对同一条记录读取两次以上的结果不一致。update操作
- 幻读:一个事务因读取到另一个事务已提交的数据。导致对同一张表读取两次以上的结果不一致。insert、delete操作
为了避免上面出现的几种情况,在标准SQL规范中,定义了4个事务隔离级别,不同的隔离级别对事务的处理不同
现在来看看MySQL数据库为我们提供的四种隔离级别(由低到高):
- Read uncommitted (读未提交):最低级别,任何情况都无法保证。
- Read committed (读已提交):可避免脏读的发生。
- Repeatable read (可重复读):可避免脏读、不可重复读的发生。
- Serializable (串行化):可避免脏读、不可重复读、幻读的发生。
大多数数据库的默认隔离级别是Read committed,比如Oracle、DB2等。
MySQL数据库的默认隔离级别是Repeatable read。
隔离级别越高,越能保证数据的完整性和一致性,但是对并发性能的影响也越大。
对于多数应用程序,可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取,而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题,在可能出现这类问题的个别场合,可以由应用程序采用悲观锁或乐观锁来控制。
第六:MySql锁
数据库锁机制是为了保障数据库数据的一致性而使各种共享资源在被并发访问的时候变得有序而设计的规则,针对不同存储引起,mysql数据库的锁机制也不一样,总的来说,分为三种:行级锁定,页面锁定和表级锁定。
总的来说,MySQL这3种锁的特性可大致归纳如下:
* 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低;
* 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高;
* 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。
MySQL的表级锁定有两种模式:表共享读锁(Table Read Lock)和表独占写锁(Table Write Lock)。
InnoDB引擎的锁机制
共享锁(S):允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁。
排他锁(X):允许获得排他锁的事务更新数据,阻止其他事务取得相同数据集的共享读锁和排他写锁。
1)共享锁和排他锁都是行锁,意向锁都是表锁,应用中我们只会使用到共享锁和排他锁,意向锁是mysql内部使用的,不需要用户干预。
2)对于UPDATE、DELETE和INSERT语句,InnoDB会自动给涉及数据集加排他锁(X);对于普通SELECT语句,InnoDB不会加任何锁,事务可以通过以下语句显示给记录集加共享锁或排他锁。
共享锁(S):SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。
排他锁(X):SELECT * FROM table_name WHERE ... FOR UPDATE。
3)InnoDB行锁是通过给索引上的索引项加锁来实现的,因此InnoDB这种行锁实现特点意味着:只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁!。
第七:MySql集群搭建之主从复制
https://www.cnblogs.com/liluxiang/p/9679427.html
https://www.cnblogs.com/gdjlc/p/12222512.html
第八:MySql集群搭建之读写分离
利用MySQL-Proxy
第九:Mycat分库分表之MyCat实现
什么是mycat:
一个彻底开源的,面向企业应用开发的“大数据库集群”
支持事务、ACID、可以替代Mysql的加强版数据库
一个可以视为“Mysql”集群的企业级数据库,用来替代昂贵的Oracle集群
一个融合内存缓存技术、Nosql技术、HDFS大数据的新型SQL Server
结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品
一个新颖的数据库中间件产品
MyCAT的目标是:低成本的将现有的单机数据库和应用平滑迁移到“云”端,解决数据存储和业务规模迅速增长情况下的数据瓶颈问题。
关键特性:
支持 SQL 92标准
支持Mysql集群,可以作为Proxy使用
支持JDBC连接ORACLE、DB2、SQL Server,将其模拟为MySQL Server使用
支持galera for mysql集群,percona-cluster或者mariadb cluster,提供高可用性数据分片集群
自动故障切换,高可用性
支持读写分离,支持Mysql双主多从,以及一主多从的模式
支持全局表,数据自动分片到多个节点,用于高效表关联查询
支持独有的基于E-R 关系的分片策略,实现了高效的表关联查询
多平台支持,部署和实施简单
mycat架构:
如图所示:MyCAT使用Mysql的通讯协议模拟成了一个Mysql服务器,并建立了完整的Schema(数据库)、Table (数据表)、User(用户)的逻辑模型,并将这套逻辑模型映射到后端的存储节点DataNode(MySQL Instance)上的真实物理库中,这样一来,所有能使用Mysql的客户端以及编程语言都能将MyCAT当成是Mysql Server来使用,不必开发新的客户端协议。
Mycat解决的问题
- 性能问题
- 数据库连接过多
- E-R分片难处理
- 可用性问题
- 成本和伸缩性问题
分片策略:
MyCAT支持水平分片与垂直分片:
水平分片:一个表格的数据分割到多个节点上,按照行分隔。
垂直分片:一个数据库中多个表格A,B,C,A存储到节点1上,B存储到节点2上,C存储到节点3上。
Mycat读写分离
数据库读写分离对于大型系统或者访问量很高的互联网应用来说,是必不可少的一个重要功能。对于MySQL来说,标准的读写分离是主从模式,一个写节点Master后面跟着多个读节点,读节点的数量取决于系统的压力,通常是1-3个读节点的配置。
Mycat读写分离和自动切换机制,需要mysql的主从复制机制配合。
mycat问题2
mycat问题1:
https://www.cnblogs.com/kingsonfu/p/10626481.html
分库分表,主从分离
https://blog.csdn.net/weishuai528/article/details/99730309
本文地址:https://blog.csdn.net/woshimenghui/article/details/107182759