关于mysql认识1.1

本文主要是关于mysql的一些个人理解，如果文中用词或者理解方面出现问题，欢迎指出。此文旨在分享我对于mysql的整一些个人理解，对于细节方面不会去深究，若有名词或者理解方面的问题，欢迎指出

Mysql

须知：在此是默认读者熟悉了sql的一些概念，在此只是记录平时经常用到的一些sql以及背后的原理

mysql的执行顺序

select[distinct]

from

join（如left join）

on

where

group by

having

union

order by

limit

Mysql的执行顺序是

1. from
2. on
3. join
4. where
5. group by
6. having
7. select
8. distinct
9. union
10. order by
11. limit

让我们一步一步去认识执行顺序

1. 首先from,拿到某个表，如果from这里有多个表，它会做一个表之间的笛卡尔积。

2. 通过on的条件去join一个表，这里假设我的on条件是两个表的某个字段相等，这时相当于将字段相等的两条记录拼接在一起

3. where在上述操作得到的临时表后筛选符合条件的记录，得到一个临时表

4. group by是将字段进行分组，就是将重复的字段合并成一个字段，分开来去展示，可以将已经分好的字段执行聚合函数。

   MySql从5.7版本开始默认开启only_full_group_by规则，规则核心原则如下，没有遵循原则的sql会被认为是不合法的sql

   1. group by后面的字段必须是select后面所有的字段,having和order by的字段根据执行顺序，它们后面的字段也必须是select里面的字段，但不像group by要求全部，它们可以选择单个字段。
   2. 如果分组列中包含具有NULL值的行，则NULL将作为一个分组返回。如果列中有多行NULL值，它们将分为一组

5. having：过滤分组，having在group by的基础上继续筛选，所以也叫组级筛选，而与之相对的where是对from的表进行行级过滤

   HAVING非常类似于WHERE。事实上，目前为止所学过的所有类型的WHERE子句都可以用HAVING来替代。唯一的差别是，WHERE过滤行，而HAVING过滤分组。不过通常having是和group by成对出现的

6. select,将所要展示的字段从临时结果集中展示出来

7. distinct :去除重复的字段

8. union：将union前后得到的表组合起来，这里要求两张表的字段是一样的，否则mysql中会将第二个表的记录组合进第一个表，而字段显示第一张表的字段。

9. order by：对上述操作产生的临时表针对某字段进行排序操作。

10. limit: 取出临时表中的前几条记录

补充：

1. join是内连接还是外连接，无非就是记录连接的方式不同。内连接inner join相当于where，相当于将条件满足的记录拼接到一起。而外连接又分为left outer join(left join)和right outer join(right join)，左外连接:A LEFT JOIN B，保持左表不变，而右表根据on的条件将满足符合的记录拼接到左表中去。右外连接反之亦然。
2. where ：由于where的执行顺序在from on join之后，条件里是不允许用临时表不存在的字段，像聚合函数、其他表的字段是不允许用的。
3. group by：group by后面的字段要用select中的所有字段

mysql函数使用

数字型函数

ABS	求绝对值
SQRT	求二次方根
MOD	求余数
CEIL 和 CEILING	两个函数功能相同，都是返回不小于参数的最小整数，即向上取整
FLOOR	向下取整，返回值转化为一个BIGINT
RAND	生成一个0~1之间的随机数，传入整数参数是，用来产生重复序列
ROUND	对所传参数进行四舍五入
SIGN	返回参数的符号
POW 和 POWER	两个函数的功能相同，都是所传参数的次方的结果值

字符型函数

LENGTH	计算字符串长度函数，返回字符串的字节长度
CONCAT	合并字符串函数，返回结果为连接参数产生的字符串，参数可以使一个或多个
INSERT	替换字符串函数
LOWER	将字符串中的字母转换为小写
UPPER	将字符串中的字母转换为大写
LEFT	从左侧字截取符串，返回字符串左边的若干个字符
RIGHT	从右侧字截取符串，返回字符串右边的若干个字符
TRIM	删除字符串左右两侧的空格
REPLACE	字符串替换函数，返回替换后的新字符串
SUBSTRING	截取字符串，返回从指定位置开始的指定长度的字符换
REVERSE	字符串反转（逆序）函数，返回与原始字符串顺序相反的字符串

日期/时间函数

函数名称	作 用
CURDATE 和 CURRENT_DATE	两个函数作用相同，返回当前系统的日期值
CURTIME 和 CURRENT_TIME	两个函数作用相同，返回当前系统的时间值
NOW 和 SYSDATE	两个函数作用相同，返回当前系统的日期和时间值
UNIX_TIMESTAMP	获取UNIX时间戳函数，返回一个以 UNIX 时间戳为基础的无符号整数
FROM_UNIXTIME	将 UNIX 时间戳转换为时间格式，与UNIX_TIMESTAMP互为反函数
MONTH	获取指定日期中的月份
MONTHNAME	获取指定日期中的月份英文名称
DAYNAME	获取指定曰期对应的星期几的英文名称
DAYOFWEEK	获取指定日期对应的一周的索引位置值
WEEK	获取指定日期是一年中的第几周，返回值的范围是否为 0〜52 或 1〜53
DAYOFYEAR	获取指定曰期是一年中的第几天，返回值范围是1~366
DAYOFMONTH	获取指定日期是一个月中是第几天，返回值范围是1~31
YEAR	获取年份，返回值范围是 1970〜2069
TIME_TO_SEC	将时间参数转换为秒数
SEC_TO_TIME	将秒数转换为时间，与TIME_TO_SEC 互为反函数
DATE_ADD 和 ADDDATE	两个函数功能相同，都是向日期添加指定的时间间隔
DATE_SUB 和 SUBDATE	两个函数功能相同，都是向日期减去指定的时间间隔
ADDTIME	时间加法运算，在原始时间上添加指定的时间
SUBTIME	时间减法运算，在原始时间上减去指定的时间
DATEDIFF	获取两个日期之间间隔，返回参数 1 减去参数 2 的值
DATE_FORMAT	格式化指定的日期，根据参数返回指定格式的值
WEEKDAY	获取指定日期在一周内的对应的工作日索引
TIMESTAMPDIFF	计算两个日期的时间差函数

聚合函数

函数名称	作用
MAX	查询指定列的最大值
MIN	查询指定列的最小值
COUNT	统计查询结果的行数
SUM	求和，返回指定列的总和
AVG	求平均值，返回指定列数据的平均值

流程控制函数

函数名称	作用
IF	判断，流程控制
IFNULL	判断是否为空
CASE	搜索语句

TRUNCATE()函数介绍

TRUNCATE(X,D) 是MySQL自带的一个系统函数。
其中，X是数值，D是保留小数的位数。
其作用就是按照小数位数，进行数值截取（此处的截取是按保留位数直接进行截取，没有四舍五入）。
 
2、数值保留规则
规则如下：
1）当 D 大于0，是对数值 X 的小数位数进行操作；

2）当 D 等于0，是将数值 X 的小数部分去除，只保留整数部分；

3）当 D 小于0，是将数值 X 的小数部分去除，并将整数部分按照 D 指定位数，用 0 替换。

mysql索引

索引是什么：

索引的作用相当于目录

可用的索引结构：B树 B+树 Hash

索引的优缺点：

优点：可以提高查询的速度

缺点：需要创建索引和维护索引，特别是有索引的数据更改时，需要更新索引，如果索引结构这时很庞大，更新一次会耗费不少时间

并不是使用了索引就保证能提高查询效率，大多数情况下，使用索引还是比全表排查快的，但是在数据量不大的情况下，假如在InnoDB搜索非主键的索引，由于要回查主键，它所花费的时间反而会比全表查询慢，索引不可以滥用。

用什么实现索引

在这里有一个很好的动态演示地址各种数据结构演示

hash索引

hash表查询提取数据是很快的，只要通过hash函数得到hash值就可以得到value,时间复杂度O(1)，即使hash表有hash冲突的情况,也可以通过链地址法去解决，在JDK1.8之前HashMap 就是通过链地址法来解决哈希冲突的。不过，JDK1.8 以后HashMap为了减少链表过长的时候搜索时间过长引入了红黑树。最大的缺点就是使用hash表作为索引，它是不支持范围和顺序查询的，如果hash表要查询一个小于500的数，hash如何能够找到呢？难道要将1-499的数都查询一遍吗。所以并没有使用hash表去作为索引

二叉搜索树

如果使用二叉搜实现，在特殊情况下，二叉搜索树会退化成链表结构，导致时间复杂度变成线性结构。

红黑树

红黑树是自平衡的二叉搜索树，但是由于二叉树的性质，会导致在数据量很大的时候，树的高度会很大，导致磁盘IO读取次数过多，例如，读取一个在底层的叶子节点，会从根节点开始找，先从硬盘读取根节点，再根据大小继续去找，这时，如果树的高度很高，就意味着要找到这个底层的叶子节点要经过O（树的高度）的磁盘IO，这个开销是很大的。那么有什么办法可以降低这个高度呢？既然限制了高度，也就是垂直方向，那么可以往水平方向发展，也就是可以从二叉树变为3、4等多叉树。从树的直观感受上来说，就是从一个“瘦高”的树变为“矮胖”的树，这就是B树

暂存研究点：

• 怎么手写红黑树

• 研究红黑树的底层原理

B-树/B树

前面说到了B树是从红黑树演变出来的自平衡多叉树，节点保存的数据量是有限的，了解过计算机底层原理这方面的话，会知到硬盘同内存打交道的单位的数据最大是4K，可能有时候有一些局部读取的原理可能会取几十K（4的整数倍），取个16K，24K也是可以的。知道了这个我们来演示一下B-树的查询过程

由于B树节点存储的是索引和数据，这会导致单个节点能够保存的索引并不高，继而导致某些情况下硬盘IO还是很高，查找效率不高，所以mysql使用了B树的变种树B+树

B+树(B-tree变种)

B+树和B树的最大区别就是B+树只有叶子节点保存索引和数据，非叶子节点保存冗余的索引。并且叶子节点之间还有指针，非叶子节点和B树一样没有指针，这也是B+树支持范围和顺序查找的原因。

为什么要将非叶子节点的数据移除？

因为一个节点它所能承载的数据量是有限的，这是因为计算机底层原理限制了磁盘和内存的交互大小，（从磁盘读取一个节点就是一次磁盘IO）所以把数据去除后，非叶子节点能够存储更多的索引，从磁盘读到内存的索引会变多，也就更容易的找到所要查询的数据，减少磁盘的IO

mysql引擎

5.7以前MySQL用的是MYISAM，5.7之后改用InnoDB

InnoDB和MYISAM最大的不同就是叶子节点的数据存放的不同，InnoDB主键索引的叶子节点存放的是主键所在的记录，副键索引存放的是主键。MYISAM无论主键索引还是副键索引存放的是指向磁盘的索引

InnoDB和MYISAM的优缺点

由于存储data的不同，也就造成了各有有缺点

InnoDB的主键存放的是记录，所以可以直接取出来，对于副键索引，还需要根据找到的主键，再去查一遍（回表），并且数据改变的时候，需要维护主键的索引，如果有索引的数据改变频繁并且索引结构复杂，会导致效率低

MYISAM由于存放的是指针，所以无论是主键还是副键，都直接找到记录所在的指针，去数据表文件查找记录，但是对比InnoDB来说，多了个根据指针查找的操作，会对效率有所降低，在数据改变时，不需要去维护指针，只需要改变数据文件中的记录

1.是否支持行级锁

MyISAM 只有表级锁(table-level locking)，而 InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。

也就说，MyISAM 一锁就是锁住了整张表，这在并发写的情况下是多么滴憨憨啊！这也是为什么 InnoDB 在并发写的时候，性能更牛皮了！

2.是否支持事务

MyISAM 不提供事务支持。

InnoDB 提供事务支持，具有提交(commit)和回滚(rollback)事务的能力。

3.是否支持外键

MyISAM 不支持，而 InnoDB 支持。

4.是否支持数据库异常崩溃后的安全恢复

MyISAM 不支持，而 InnoDB 支持。

使用 InnoDB 的数据库在异常崩溃后，数据库重新启动的时候会保证数据库恢复到崩溃前的状态。这个恢复的过程依赖于 redo log 。

• MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性，使用 undo log(回滚日志) 来保证事务的原子性。//具体细节实现
• MySQL InnoDB 引擎通过 锁机制、MVCC 等手段来保证事务的隔离性（ 默认支持的隔离级别是 REPEATABLE-READ ）。//具体细节
• 保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。

5.是否支持 MVCC（版本控制）

MyISAM 不支持，而 InnoDB 支持。

讲真，这个对比有点废话，毕竟 MyISAM 连行级锁都不支持。

MVCC 可以看作是行级锁的一个升级，可以有效减少加锁操作，提供性能。//MVCC粒度比行级锁还小

mysql锁机制

mysql事务以及实现机制

mysql性能优化

mysql性能优化可以从以下方面入手：

1. 设计合理的表结构

   • 不要使用无法加索引的类型作为关键字段，比如 text类型
   • 为了避免联表查询，有时候可以适当的数据冗余
   • 根据业务，选择合理的引擎

2. 建立合适的索引结构

   • 如果在SQL里使用了MySQL部分自带函数，索引将失效，同时将无法

   使用 MySQL 的 Query Cache**，比如** LEFT(), SUBSTR(), TO_DAYS()

   DATE_FORMAT(), 等，如果使用了 OR 或 IN**，索引也将失效**，就是改变了索引字段的方法

3. 编写简洁高效的sql语句

   • 不要在where 子句中的“=”左边进行算术或表达式运算，否则系统将可能无法正确使用索引

   • 尽量不要在where条件中使用函数，否则将不能使用索引

Mysql慢查询优化

1. 找到MySQL的配置文件my.ini文件

[mysqld]下的

slow-query-log=1  //开启mysql慢查询记录

slow_query_log_file="slow-query.log"	//记录位置

long_query_time=3	//记录慢查询阈值,超过这个时间的查询都会被记录到log中

2. 查找到mysql执行缓慢的sql语句后，可以通过 EXPLAIN 获取 MySQL 如何执行 SELECT 语句的信息

   例如：

   EXPLAIN SELECT

   • FROM
     dept
     WHERE
     dept.dname = ‘开发部’

得到

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LdYFRRzr-1627906999260)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20210802163529191.png)]

每个列的解释如下：

•select_type ：表示 SELECT 的 类型，常见的取值有 SIMPLE （简单表，即不使用表连接或者子查询）、 PRIMARY （主查询，即外层的查询）、 UNION （ UNION 中的第二个或者后面的查询语句）、 SUBQUERY （子查询中的第一个 SELECT ）等。

•table ：输出结果集的表。

•type ：表示表的连接类型，性能由好到差的连接类型为 system （表中仅有一行，即常量表）、 const （单表中最多有一个匹配行，例如 primary key 或者 unique index ）、 eq_ref （对于前面的每一行，在此表中只查询一条记录，简单来说，就是多表连接中使用 primary key 或者 unique index ）、 ref （与 eq_ref 类似，区别在于不是使用 primary key 或者 unique index ，而是使用普通的索引）、 ref_or_null （ 与 ref 类似，区别在于条件中包含对 NULL 的查询 ） 、 index_merge ( 索引合并优化 ) 、 unique_subquery （ in 的后面是一个查询主键字段的子查询）、 index_subquery （ 与 unique_subquery 类似，区别在于 in 的后面是查询非唯一索引字段的子查询）、 range （单表中的范围查询）、 index （对于前面的每一行，都通过查询索引来得到数据）、 all （对于前面的每一行，都通过全表扫描来得到数据）。

•possible_keys ：表示查询时，可能使用的索引。
•key ：表示实际使用的索引。
•key_len ：索引字段的长度。
•rows ：扫描行的数量。
•Extra ：执行情况的说明和描述。

可以看到rows是6，这说明是全表扫描,我表中记录共有6条。

3. 如果我们对dname加上索引

create index dept_dname on dept(dname);

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VvjNpsVx-1627906999260)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20210802163927170.png)]

可以看到row变成了1,说明加快了查询

4. 还可以使用MySQLdumpslow命令，mysqldumpslow - mysql官方提供的慢查询日志分析工具

   例如：MySQLdumpslow -s c -t 10 /tmp/slow-log

   这会输出记录次数最多的10条SQL语句，其中：

   -s, 是表示按照何种方式排序，c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序， ac、at、al、ar，表示相应的倒叙;

   -t, 是top n的意思，即为返回前面多少条的数据;

   -g, 后边可以写一个正则匹配模式，大小写不敏感的;

MySQL索引的注意事项

1.选择合适的字段创建索引：

• 不为 NULL 的字段 ：索引字段的数据应该尽量不为 NULL，因为对于数据为 NULL 的字段，数据库较难优化。如果字段频繁被查询，但又避免不了为 NULL，建议使用 0,1,true,false 这样语义较为清晰的短值或短字符作为替代。
• 被频繁查询的字段 ：我们创建索引的字段应该是查询操作非常频繁的字段。
• 被经常频繁用于连接的字段 ：经常用于连接的字段可能是一些外键列，对于外键列并不一定要建立外键，只是说该列涉及到表与表的关系。对于频繁被连接查询的字段，可以考虑建立索引，提高多表连接查询的效率。
• order by 字句中的字段，where 子句中字段，最常用的sql语句中字段，应建立索引。
• 对大数据量表建立聚集索引，避免更新操作带来的碎片。
• 大文本字段不建立为索引，如果要对大文本字段进行检索，可以考虑全文索引
• 尽量使用短索引，一般对int、char/varchar、date/time 等类型的字段建立索引
• Decimal 类型字段不要单独建立为索引，但覆盖索引可以包含这些字段

2.被频繁更新的字段应该慎重建立索引。

虽然索引能带来查询上的效率，但是维护索引的成本也是不小的。 如果一个字段不被经常查询，反而被经常修改，那么就更不应该在这种字段上建立索引了。

3.尽可能的考虑建立联合索引而不是单列索引。

因为索引是需要占用磁盘空间的，可以简单理解为每个索引都对应着一颗 B+树。如果一个表的字段过多，索引过多，那么当这个表的数据达到一个体量后，索引占用的空间也是很多的，且修改索引时，耗费的时间也是较多的。如果是联合索引，多个字段在一个索引上，那么将会节约很大磁盘空间，且修改数据的操作效率也会提升。

5.考虑在字符串类型的字段上使用前缀索引代替普通索引。

前缀索引仅限于字符串类型，较普通索引会占用更小的空间，所以可以考虑使用前缀索引带替普通索引。

**6.

索引的失效情况

• 针对索引字段使用 >, >=, =, <, <=, IF NULL和BETWEEN将会使用索引， 如果对某个索引字段进行 LIKE 查询，使用 LIKE ‘%abc%’，不能使用索引，使用 LIKE ‘abc%’将能够使用索引

• 如果在SQL里使用了MySQL部分自带函数，索引将失效，同时将无法使用 MySQL 的 Query Cache，比如 LEFT(), SUBSTR(), TO_DAYS() DATE_FORMAT(), 等，如果使用了 OR 或 IN，索引也将失效如果在SQL里

• 不要在where 子句中的“=”左边进行算术或表达式运算，否则系统将可能无法正确使用索引

• 尽量不要在where条件中使用函数，否则将不能使用索引

MySQL 如何为表字段添加索引？

1.添加 PRIMARY KEY（主键索引）

ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )

2.添加 UNIQUE(唯一索引)

ALTER TABLE `table_name` ADD UNIQUE ( `column` )

3.添加 INDEX(普通索引)

ALTER TABLE `table_name` ADD INDEX index_name ( `column` )

4.添加 FULLTEXT(全文索引)

ALTER TABLE `table_name` ADD FULLTEXT ( `column`)

5.添加多列索引

ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )

mysql分库分表

MySQL的主从复制以及读写分离

mysql复制流程

1. 主从复制：在每个事务更新数据完成之前，master在二进制日志记录这些改变。写入二进制日志完成后，master通知存储引擎提交事务。

2. Slave将master的binary log复制到其中继日志。首先slave开始一个工作线程（I/O），I/O线程在master上打开一个普通的连接，然后开始binlog dump process。binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件，I/O线程将这些事件写入中继日志。

3. Sql slave thread（sql从线程）处理该过程的最后一步，sql线程从中继日志读取事件，并重放其中的事件而更新slave数据，使其与master中的数据一致，只要该线程与I/O线程保持一致，中继日志通常会位于os缓存中，所以中继日志的开销很小。

4. 查看主从是否延迟
   查看从库的参数:show slave status\G;
   Read_Master_Log_Pos: 21416041 传输过来的主库日志的位置
   Exec_Master_Log_Pos: 21416041 执行到主库日志的位置
   Seconds_Behind_Master: 0 从库延迟秒

   5.主从延迟的因素
   网络延迟
   主库高并发
   从库高并发
   一般解决方式是多添加几台slave，这样从库的压力低了。或者再添加一台只用于
   备份的slave，可以最大限度的防止主从延迟

   6.主从同步延迟原理
   MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的binlog是顺序写
   所以效率很高，从库的i/o线程获取binlog也是顺序读，而sql线程执行relaylog时
   是随即写，因此成本会比较高，而且主库是可以并发的，而从库的sql线程只能等
   上一个DDL操作结束之后才能执行新的DDL操作，而且当从库的查询并发高时，从库
   的sql线程操作还可能会与查询语句产生lock争用。

   MySQL主从复制–主库已有数据的解决方案

   1. 锁定主数据库，只允许读取不允许写入，防止备份过程中，主库和从库数据不一致；
   2. flush tables with read lock；
   3. 使用mysqldump来导出数据，导出的数据放到从库里面
   4. 启动主从复制
   5. 解锁主数据库：unlock tables；

mysql读写分离原理

• 读写分离就是在主服务器上修改，数据会同步到从服务器，从服务器只能提供读取数据，不能写入，实现备份的同时也实现了数据库性能的优化，以及提升了服务器安全。

常见的读写分离实现：

1. 基于程序代码内部实现

在代码中根据select 、insert进行路由分类，这类方法也是目前生产环境下应用最广泛的。优点是性能较好，因为程序在代码中实现，不需要增加额外的硬件开支，缺点是需要开发人员来实现，运维人员无从下手。

2. 基于中间代理层实现

代理一般介于应用服务器和数据库服务器之间，代理数据库服务器接收到应用服务器的请求后根据判断后转发到，后端数据库，有以下代表性的程序。

（1）mysql_proxy。mysql_proxy是Mysql的一个开源项目，通过其自带的lua脚本进行sql判断。

（2）Atlas。是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条。支持事物以及存储过程。

（3）Amoeba。由阿里巴巴集团在职员工陈思儒使用序java语言进行开发，阿里巴巴集团将其用户生产环境下，但是他并不支持事物以及存储过程。

mysql主从复制实现

mysql读写分离ShardingSphere实现

第一步:导入依赖

//核心依赖
<dependency>
    <groupId>io.shardingjdbc</groupId>
    <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
    <version>2.0.0.M3</version>
</dependency>
//驱动
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
</dependency>
//连接池
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>druid</artifactId>
</dependency>

//建一个application.properties文件存放,并把其他数据源配置注释掉
//把下面的数据库名字密码改成自己的
sharding.jdbc.datasource.names=ds_master,ds_slave

# 主数据源
sharding.jdbc.datasource.ds_master.type=com.alibaba.druid.pool.DruidDataSource
sharding.jdbc.datasource.ds_master.driver-class-name=com.mysql.jdbc.Driver
sharding.jdbc.datasource.ds_master.url=jdbc:mysql://localhost:3306/clouddb02?characterEncoding=utf-8
sharding.jdbc.datasource.ds_master.username=root
sharding.jdbc.datasource.ds_master.password=root

# 从数据源
sharding.jdbc.datasource.ds_slave.type=com.alibaba.druid.pool.DruidDataSource
sharding.jdbc.datasource.ds_slave.driver-class-name=com.mysql.jdbc.Driver
sharding.jdbc.datasource.ds_slave.url=jdbc:mysql://localhost:3306/clouddb03?characterEncoding=utf-8
sharding.jdbc.datasource.ds_slave.username=root
sharding.jdbc.datasource.ds_slave.password=root

# 读写分离配置  round_robin指定轮询
sharding.jdbc.config.masterslave.load-balance-algorithm-type=round_robin
sharding.jdbc.config.masterslave.name=dataSource
sharding.jdbc.config.masterslave.master-data-source-name=ds_master
sharding.jdbc.config.masterslave.slave-data-source-names=ds_slave

SpringBoot整合ShardingSphere

s-name=com.mysql.jdbc.Driver
sharding.jdbc.datasource.ds_slave.url=jdbc:mysql://localhost:3306/clouddb03?characterEncoding=utf-8
sharding.jdbc.datasource.ds_slave.username=root
sharding.jdbc.datasource.ds_slave.password=root

读写分离配置 round_robin指定轮询

sharding.jdbc.config.masterslave.load-balance-algorithm-type=round_robin
sharding.jdbc.config.masterslave.name=dataSource
sharding.jdbc.config.masterslave.master-data-source-name=ds_master
sharding.jdbc.config.masterslave.slave-data-source-names=ds_slave

### SpringBoot整合ShardingSphere