数据库设计
数据库三大范式
第一范式：1NF是对属性的原子性约束，要求属性(列)具有原子性，不可再分解；(只要是关系型数据库都满足1NF)。
第二范式：2NF是对记录的惟一性约束，表中的记录是唯一的, 就满足2NF, 通常我们设计一个主键来实现，主键不能包含业务逻辑。
第三范式：3NF是对字段冗余性的约束，它要求字段没有冗余。 没有冗余的数据库设计可以做到。
但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是： 在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。
降低范式就是增加字段，允许冗余。
数据类型
数据类型的选择原则：更简单或者占用空间更小。
1.如果长度能够满足，整型尽量使用tinyint、smallint、medium_int而非int。 2.如果字符串长度确定，采用char类型。 3.如果varchar能够满足，不采用text类型。 4.精度要求较高的使用decimal类型，也可以使用BIGINT，比如精确两位小数就乘以100后保存。 5尽量采用timestamp而非datetime。
| 类型 |
占据字节 |
描述 |
| datetime |
8字节 |
'1000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.999999 |
| timestamp |
4字节 |
'1970-01-01 00:00:01.000000' to '2038-01-19 03:14:07.999999' |
相比datetime，timestamp占用更少的空间，以UTC的格式储存自动转换时区。
避免空值
MySQL中字段为NULL时依然占用空间，会使索引、索引统计更加复杂。从NULL值更新到非NULL无法做到原地更新，容易发生索引分裂影响性能。尽可能将NULL值用有意义的值代替，
也能避免SQL语句里面包含 is not null的判断。
text类型优化
由于text字段储存大量数据，表容量会很早涨上去，影响其他字段的查询性能。建议抽取出来放在子表里，用业务主键关联。
索引
索引的分类
普通索引：最基本的索引。
组合索引：多个字段上建立的索引，能够加速复合查询条件的检索。
唯一索引：与普通索引类似，但索引列的值必须唯一，允许有空值。
组合唯一索引：列值的组合必须唯一。
主键索引：特殊的唯一索引，用于唯一标识数据表中的某一条记录，不允许有空值，一般用primary key约束。
全文索引：用于海量文本的查询，MySQL5.6之后的InnoDB和MyISAM均支持全文索引。由于查询精度以及扩展性不佳，更多的企业选择Elasticsearch。
索引的实现原理
数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用 B 树及其变种 B+ 树。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。
为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。
上图展示了一种可能的索引方式。左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快 Col2 的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在 O(log2n)的复杂度内获取到相应数据。
创建索引可以大大提高系统的性能。
第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。
第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
也许会有人要问：增加索引有如此多的优点，为什么不对表中的每一个列创建一个索引呢？因为，增加索引也有许多不利的方面。
第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
根据数据库的功能，可以在数据库设计器中创建三种索引：唯一索引、主键索引和聚集索引。
唯一索引是不允许其中任何两行具有相同索引值的索引。
当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在 employee 表中职员的姓(lname)上创建了唯一索引，则任何两个员工都不能同姓。
主键索引数据库表经常有一列或列组合，其值唯一标识表中的每一行。该列称为表的主键。在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。
聚集索引在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。
局部性原理与磁盘预读
由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分之一，因此为了提高效率，要尽量减少磁盘 I/O。为了达到这个目的，磁盘往往不是严格按需读取，
而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。
程序运行期间所需要的数据通常比较集中。由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高 I/O 效率。预读的长度一般为页（page）的整倍数。
页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为4k），主存和磁盘以页为单位交换数据。
当程序要读取的数据不在主存中时，会触发一个缺页异常，此时系统会向磁盘发出读盘信号，磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中，然后异常返回，程序继续运行。
B-/+Tree 索引的性能分析
上面说过一般使用磁盘 I/O 次数评价索引结构的优劣。先从 B-Tree 分析，根据 B-Tree 的定义，可知检索一次最多需要访问 h 个节点。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，
这样每个节点只需要一次 I/O 就可以完全载入。为了达到这个目的，在实际实现 B-Tree 还需要使用如下技巧：每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，
加之计算机存储分配都是按页对齐的，就实现了一个 node 只需一次 I/O。B-Tree 中一次检索最多需要 h-1 次 I/O（根节点常驻内存），渐进复杂度为 O(h)=O(logdN)。一般实际应用中，出度 d 是非常大的数字，
通常超过 100，因此 h 非常小（通常不超过 3）。而红黑树这种结构，h 明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，所以红黑树的 I/O 渐进复杂度也为 O(h)，
效率明显比 B-Tree 差很多。综上所述，用 B-Tree 作为索引结构效率是非常高的.
Explain执行计划
explain select * from table where table.id = 1
运行上面的sql语句后你会看到，下面的表头信息：
table | type | possible_keys | key | key_len | ref | rows | Extra
EXPLAIN列的解释
table 显示这一行的数据是关于哪张表的
type
这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL 说明：不同连接类型的解释（按照效率高低的顺序排序） system：表只有一行：system表。这是const连接类型的特殊情况。 const ：表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待。 eq_ref：在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用。 ref：这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。
这个类型严重依赖于根据索引匹配的记录多少—越少越好。 range：这个连接类型使用索引返回一个范围中的行，比如使用>或<查找东西时发生的情况。 index：这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据）。 ALL：这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免。
possible_keys
显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句
key
实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MYSQL会选择优化不足的索引。这种情况下，可以在SELECT语句中使用USE INDEX（indexname）来强制使用一个索引或者用
IGNORE INDEX（indexname）来强制MYSQL忽略索引
key_len
使用的索引的长度。在不损失精确性的情况下，长度越短越好
ref
显示索引的哪一列被使用了，如果可能的话，是一个常数
rows
MYSQL认为必须检查的用来返回请求数据的行数
Extra
关于MYSQL如何解析查询的额外信息。将在表4.3中讨论，但这里可以看到的坏的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，结果是检索会很慢 说明：extra列返回的描述的意义 Distinct ：一旦mysql找到了与行相联合匹配的行，就不再搜索了。 Not exists ：mysql优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了。 Range checked for each Record（index map:#） ：没有找到理想的索引，因此对从前面表中来的每一个行组合，mysql检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一。 Using filesort ：看到这个的时候，查询就需要优化了。mysql需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行。 Using index ：列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候。 Using temporary ：看到这个的时候，查询需要优化了。这里，mysql需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上。 Where used ：使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题。 因此，弄明白了explain语法返回的每一项结果，我们就能知道查询大致的运行时间了，如果查询里没有用到索引、或者需要扫描的行过多，那么可以感到明显的延迟。因此需要改变查询方式或者新建索引。
mysql中的explain语法可以帮助我们改写查询，优化表的结构和索引的设置，从而最大地提高查询效率。当然，在大规模数据量时，索引的建立和维护的代价也是很高的，往往需要较长的时间和较大的空间，
如果在不同的列组合上建立索引，空间的开销会更大。因此索引最好设置在需要经常查询的字段中。
索引的代价
占用磁盘空间,对DML(update、delete、insert)语句的效率影响,增删改会对索引影响，因为索引要重新整理。
| 存储引擎 |
允许的索引类型 |
| myisam |
btree |
| innodb |
btree |
| memory/yeap |
Hash,btree |
那些列上适合添加索引
1.在where条件经常使用 2.该字段的内容不是唯一的几个值 3.字段内容不是频繁变化
查询所用使用率
show status like ‘handler_read%’;
注意：
handler_read_key:这个值越高越好，越高表示使用索引查询到的次数。
handler_read_rnd_next:这个值越高，说明查询低效。
索引优化
1.分页查询很重要，如果查询数据量超过30%，MYSQL不会使用索引。 2.单表索引数不超过5个、单个索引字段数不超过5个。 3.字符串可使用前缀索引，前缀长度控制在5-8个字符。 4.字段唯一性太低，增加索引没有意义，如：是否删除、性别。 5.合理使用覆盖索引，如下所示： select login_name, nick_name from member where login_name = ? login_name, nick_name两个字段建立组合索引，比login_name简单索引要更快
SQL优化
show status
使用show status查看MySQL服务器状态信息的常用命令
| mysql数据库启动了多少时间 show status like 'uptime'; |
| show stauts like 'com_select' show stauts like 'com_insert' ...类推 update delete（显示数据库的查询，更新，添加，删除的次数） |
| show [session|global] status like .... 如果你不写 [session|global] 默认是session 会话，指取出当前窗口的执行，如果你想看所有(从mysql 启动到现在，则应该 global) |
| 显示mysql数据库的连接数 show status like 'connections '; |
| 显示慢查询次数 show status like 'slow_queries'; |
慢查询
什么是慢查询
MySQL默认10秒内没有响应SQL结果,则为慢查询可以去修改MySQL慢查询默认时间。
如何修改慢查询
| --查询慢查询时间 show variables like 'long_query_time'; --修改慢查询时间 set long_query_time=1; ---但是重启mysql之后，long_query_time依然是my.ini中的值 |
如何将慢查询定位到日志中
在默认情况下，我们的mysql不会记录慢查询，需要在启动mysql时候，指定记录慢查询才可以 bin\mysqld.exe --safe-mode --slow-query-log [mysql5.5 可以在my.ini指定]（安全模式启动，数据库将操作写入日志，以备恢复） bin\mysqld.exe –log-slow-queries=D:/test.log [低版本mysql5.0可以在my.ini指定] 先关闭mysql,再启动, 如果启用了慢查询日志，默认把这个文件放在 my.ini 文件中记录的位置 #Path to the database root datadir=" C:/ProgramData/MySQL/MySQL Server 5.5/Data/"
分批处理
鱼塘挖开小口子放水，水面有各种漂浮物。浮萍和树叶总能顺利通过出水口，而树枝会挡住其他物体通过，有时还会卡住，需要人工清理。MySQL就是鱼塘，最大并发数和网络带宽就是出水口，用户SQL就是漂浮物。
不带分页参数的查询或者影响大量数据的update和delete操作，都是树枝，我们要把它打散分批处理，举例说明：业务描述：更新用户所有已过期的优惠券为不可用状态。SQL语句：
update status=0 FROMcoupon WHERE expire_date <= #{currentDate} and status=1;如果大量优惠券需要更新为不可用状态，执行这条SQL可能会堵死其他SQL，分批处理伪代码如下：
| int pageNo = 1; |
操作符<>优化
通常<>操作符无法使用索引，举例如下，查询金额不为100元的订单：select id from orders where amount != 100;如果金额为100的订单极少，这种数据分布严重不均的情况下，有可能使用索引。
鉴于这种不确定性，采用union聚合搜索结果，改写方法如下： (select id from orders where amount > 100) union all(select id from orders where amount < 100 and amount > 0)
OR优化
在Innodb引擎下or无法使用组合索引，比如： select id，product_name from orders where mobile_no = '13421800407' or user_id = 100; OR无法命中mobileno + userid的组合索引，可采用union，如下所示： (select id，product_name from orders where mobile_no = '13421800407') union(select id，product_name from orders where user_id = 100); 此时id和product_name字段都有索引，查询才最高效。
IN优化
IN适合主表大子表小，EXIST适合主表小子表大。由于查询优化器的不断升级，很多场景这两者性能差不多一样了。 尝试改为join查询，举例如下： select id from orders where user_id in (select id from user where level = 'VIP'); 采用JOIN如下所示： select o.id from orders o left join user u on o.user_id = u.id where u.level = 'VIP';
不做列运算
通常在查询条件列运算会导致索引失效，如下所示：查询当日订单 select id from order where date_format(create_time，'%Y-%m-%d') = '2019-07-01'; date_format函数会导致这个查询无法使用索引，改写后： select id from order where create_time between '2019-07-01 00:00:00' and '2019-07-01 23:59:59';
避免Select all
如果不查询表中所有的列，避免使用 SELECT *，它会进行全表扫描，不能有效利用索引。
Like优化
like用于模糊查询，举个例子（field已建立索引）： SELECT column FROM table WHERE field like '%keyword%'; 这个查询未命中索引，换成下面的写法： SELECT column FROM table WHERE field like 'keyword%'; 去除了前面的%查询将会命中索引，但是产品经理一定要前后模糊匹配呢？全文索引fulltext可以尝试一下，但Elasticsearch才是终极武器。
Join优化
join的实现是采用Nested Loop Join算法，就是通过驱动表的结果集作为基础数据，通过该结数据作为过滤条件到下一个表中循环查询数据，然后合并结果。如果有多个join，则将前面的结果集作为循环数据，
再次到后一个表中查询数据。
1.驱动表和被驱动表尽可能增加查询条件，满足ON的条件而少用Where，用小结果集驱动大结果集。
2.被驱动表的join字段上加上索引，无法建立索引的时候，设置足够的Join Buffer Size。
3.禁止join连接三个以上的表，尝试增加冗余字段。
Limit优化
limit用于分页查询时越往后翻性能越差，解决的原则：缩小扫描范围 ，如下所示： select * from orders order by id desc limit 100000,10 耗时0.4秒select * from orders order by id desc limit 1000000,10耗时5.2秒 先筛选出ID缩小查询范围，写法如下： select * from orders where id > (select id from orders order by id desc limit 1000000, 1) order by id desc limit 0,10耗时0.5秒 如果查询条件仅有主键ID，写法如下： select id from orders where id between 1000000 and 1000010 order by id desc耗时0.3秒 如果以上方案依然很慢呢？只好用游标了，感兴趣的朋友阅读JDBC使用游标实现分页查询的方法;
MySQL性能
最大数据量
抛开数据量和并发数，谈性能都是耍流氓 。MySQL没有限制单表最大记录数，它取决于操作系统对文件大小的限制。
| 文件系统 |
单文件大小限制 |
| FAT32 |
最大4G |
| NTFS |
最大64GB |
| NTFS5.0 |
最大2TB |
| EXT2 |
块大小为1024字节，文件最大容量16GB；块大小为4096字节，文件最大容量2TB |
| EXT3 |
块大小为4KB，文件最大容量为4TB |
| EXT4 |
理论可以大于16TB |
《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB，才推荐分库分表。性能由综合因素决定，抛开业务复杂度，影响程度依次是硬件配置、MySQL配置、数据表设计、索引优化。
500万这个值仅供参考，并非铁律。博主曾经操作过超过4亿行数据的单表，分页查询最新的20条记录耗时0.6秒，SQL语句大致是
select field_1,field_2 from table where id < #{prePageMinId} order by id desc limit 20，prePageMinId是上一页数据记录的最小ID。虽然当时查询速度还凑合，随着数据不断增长，
有朝一日必定不堪重负。分库分表是个周期长而风险高的大活儿，应该尽可能在当前结构上优化，比如升级硬件、迁移历史数据等等，实在没辙了再分。
最大并发数
并发数是指同一时刻数据库能处理多少个请求，由maxconnections和maxuserconnections决定。maxconnections是指MySQL实例的最大连接数，上限值是16384，maxuserconnections是指每个数据库用户的
最大连接数。MySQL会为每个连接提供缓冲区，意味着消耗更多的内存。如果连接数设置太高硬件吃不消，太低又不能充分利用硬件。一般要求两者比值超过10%，计算方法如下： max_used_connections / max_connections * 100% = 3/100 *100% ≈ 3% 查看最大连接数与响应最大连接数： show variables like '%max_connections%';show variables like '%max_user_connections%'; 在配置文件my.cnf中修改最大连接数 [mysqld]max_connections = 100max_used_connections = 20
查询耗时0.5秒
建议将单次查询耗时控制在0.5秒以内，0.5秒是个经验值，源于用户体验的 3秒原则 。如果用户的操作3秒内没有响应，将会厌烦甚至退出。响应时间=客户端UI渲染耗时+网络请求耗时+应用程序处理耗时+查询数据库耗时，
0.5秒就是留给数据库1/6的处理时间。
实施原则
相比NoSQL数据库，MySQL是个娇气脆弱的家伙。如今大家都会搞点分布式，应用程序扩容比数据库要容易得多，所以实施原则是数据库少干活，应用程序多干活 。
1.充分利用但不滥用索引，须知索引也消耗磁盘和CPU。
2.不推荐使用数据库函数格式化数据，交给应用程序处理。
3.不推荐使用外键约束，用应用程序保证数据准确性。
4.写多读少的场景，不推荐使用唯一索引，用应用程序保证唯一性。
5.适当冗余字段，尝试创建中间表，用应用程序计算中间结果，用空间换时间。
6.不允许执行极度耗时的事务，配合应用程序拆分成更小的事务。
7.预估重要数据表（比如订单表）的负载和数据增长态势，提前优化。
MySQL数据引擎
使用的存储引擎 myisam / innodb/ memory myisam 存储: 如果表对事务要求不高，同时是以查询和添加为主的，我们考虑使用myisam存储引擎. ,比如 bbs 中的 发帖表，回复表. INNODB 存储: 对事务要求高，保存的数据都是重要数据，我们建议使用INNODB,比如订单表，账号表. MyISAM 和 INNODB的区别 1. 事务安全（MyISAM不支持事务，INNODB支持事务） 2. 查询和添加速度（MyISAM批量插入速度快） 3. 支持全文索引（MyISAM支持全文索引，INNODB不支持全文索引） 4. 锁机制（MyISAM时表锁，innodb是行锁） 5. 外键 MyISAM 不支持外键， INNODB支持外键. (在PHP开发中，通常不设置外键，通常是在程序中保证数据的一致) Memory 存储，比如我们数据变化频繁，不需要入库，同时又频繁的查询和修改，我们考虑使用memory, 速度极快. （如果mysql重启的话，数据就不存在了）
Myisam注意事项
如果数据库的存储引擎是myisam,请一定记住要定时进行碎片整理 举例说明: create table test100(id int unsigned ,name varchar(32))engine= myisam; insert into test100 values(1,’aaaaa’); insert into test100 values(2,’bbbb’); insert into test100 values(3,’ccccc’); insert into test100 select id, name from test100; 我们应该定期对myisam进行整理 optimize table test100;
分表分库
垂直拆分
垂直拆分就是要把表按模块划分到不同数据库表中（当然原则还是不破坏第三范式），这种拆分在大型网站的演变过程中是很常见的。当一个网站还在很小的时候，只有小量的人来开发和维护，各模块和表都在一起，
当网站不断丰富和壮大的时候，也会变成多个子系统来支撑，这时就有按模块和功能把表划分出来的需求。其实，相对于垂直切分更进一步的是服务化改造，说得简单就是要把原来强耦合的系统拆分成多个弱耦合的服务，
通过服务间的调用来满足业务需求看，因此表拆出来后要通过服务的形式暴露出去，而不是直接调用不同模块的表，淘宝在架构不断演变过程，最重要的一环就是服务化改造，
把用户、交易、店铺、宝贝这些核心的概念抽取成独立的服务，也非常有利于进行局部的优化和治理，保障核心模块的稳定性。
垂直拆分用于分布式场景。
水平拆分
上面谈到垂直切分只是把表按模块划分到不同数据库，但没有解决单表大数据量的问题，而水平切分就是要把一个表按照某种规则把数据划分到不同表或数据库里。例如像计费系统，通过按时间来划分表就比较合适，
因为系统都是处理某一时间段的数据。而像SaaS应用，通过按用户维度来划分数据比较合适，因为用户与用户之间的隔离的，一般不存在处理多个用户数据的情况，简单的按user_id范围来水平切分
通俗理解：水平拆分行，行数据拆分到不同表中， 垂直拆分列，表数据拆分到不同表中.
如何使用水平拆分数据库
使用水平分割拆分表，具体根据业务需求，有的按照注册时间、取摸、账号规则、年份等。
1.使用取摸方式分表
首先我创建三张表 user0 / user1 /user2 , 然后我再创建 uuid表，该表的作用就是提供自增的id。
create table user0(
id int unsigned primary key ,
name varchar(32) not null default '',
pwd varchar(32) not null default '')
engine=myisam charset utf8;
create table user1(
id int unsigned primary key ,
name varchar(32) not null default '',
pwd varchar(32) not null default '')
engine=myisam charset utf8;
create table user2(
id int unsigned primary key ,
name varchar(32) not null default '',
pwd varchar(32) not null default '')
engine=myisam charset utf8;
create table uuid(id int unsigned primary key auto_increment)engine=myisam charset utf8;
2.POM文件创建一个demo项目
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.1.RELEASE</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
3.Service代码
@Service publicclass UserService { @Autowired private JdbcTemplate jdbcTemplate; public String regit(String name, String pwd) { // 1.先获取到 自定增长ID String idInsertSQL = "INSERT INTO uuid VALUES (NULL);"; jdbcTemplate.update(idInsertSQL); Long insertId = jdbcTemplate.queryForObject("select last_insert_id()", Long.class); // 2.判断存储表名称 String tableName = "user" + insertId % 3; // 3.注册数据 String insertUserSql = "INSERT INTO " + tableName + " VALUES ('" + insertId + "','" + name + "','" + pwd + "');"; System.out.println("insertUserSql:" + insertUserSql); jdbcTemplate.update(insertUserSql); return"success"; } public String get(Long id) { String tableName = "user" + id % 3; String sql = "select name from " + tableName + " where id="+id; System.out.println("SQL:" + sql); String name = jdbcTemplate.queryForObject(sql, String.class); returnname; } }
4.Controller代码
@RestController publicclass UserController { @Autowired private UserService userService; @RequestMapping("/regit") public String regit(String name, String pwd) { returnuserService.regit(name, pwd); } @RequestMapping("/get") public String get(Long id) { String name = userService.get(id); returnname; } }
5.配置文件
spring.datasource.url=jdbc:mysql://localhost:3306/test spring.datasource.username=root spring.datasource.password=root spring.datasource.driver-class-name=com.mysql.jdbc.Driver
主从复制
1.解决了哪些问题
1.数据如何不被丢失
2.备份
3.读写分离
4.数据库负载均衡
5.高可用
2.服务器准备
192.168.110.177 主服务器 master 192.168.110.178 从服务器slave
2.1修改主(master)服务器
vi /etc/my.cnf 新增以下内容 server_id=177 ###服务器id log-bin=mysql-bin ###开启日志文件
2.1.1 重启服务器
service mysqld start
service iptables stop
2.1.2 主服务器给从服务器账号授权
GRANT REPLICATION SLAVE ON *.* to 'mysync'@'%' identified by 'q123456'; //一般不用root帐号，“%”表示所有客户端都可能连，只要帐号，密码正确，此处可用具体客户端IP代替，如192.168.145.226，加强安全。
2.1.3登录主服务器的mysql，查询master的状态
show master status;
//如果结果为null,则主服务器my.cf没有配置好.
2.2. 修改从(slave)服务器
server_id=178
log-bin=mysql-bin
binlog_do_db=test
change master to master_host='192.168.110.177',master_user='mysync',master_password='q123456',
master_log_file='mysql-bin.000002',master_log_pos=343;
2.2.1. 启动同步
start slave
2.2.2 检查从服务器复制功能状态
SHOW SLAVE STATUS Slave_IO_Running: Yes //此状态必须YES Slave_SQL_Running: Yes //此状态必须YES
读写分离
读写分离的好处
1）分摊服务器压力，提高机器的系统处理效率读写分离适用于读远比写的场景，如果有一台服务器，当select很多时，update和delete会被这些select访问中的数据堵塞，等待select结束，并发性能并不高，
而主从只负责各自的写和读，极大程度的缓解X锁和S锁争用；假如我们有1主3从，不考虑上述1中提到的从库单方面设置，假设现在1分钟内有10条写入，150条读取。那么，1主3从相当于共计40条写入，而读取总数没变，
因此平均下来每台服务器承担了10条写入和50条读取（主库不承担读取操作）。因此，虽然写入没变，但是读取大大分摊了，提高了系统性能。另外，当读取被分摊后，又间接提高了写入的性能。所以，总体性能提高了，
说白了就是拿机器和带宽换性能； 2）增加冗余，提高服务可用性，当一台数据库服务器宕机后可以调整另外一台从库以最快速度恢复服务s
主从复制原理
依赖于二进制日志，binary-log.二进制日志中记录引起数据库发生改变的语句 Insert 、delete、update、create table
MyCat
什么是 Mycat
是一个开源的分布式数据库系统，但是因为数据库一般都有自己的数据库引擎，而Mycat并没有属于自己的独有数据库引擎，所有严格意义上说并不能算是一个完整的数据库系统，只能说是一个在应用和数据库之间起桥梁作用的
中间件。在Mycat中间件出现之前，MySQL主从复制集群，如果要实现读写分离，一般是在程序段实现，这样就带来了一个问题，即数据段和程序的耦合度太高，如果数据库的地址发生了改变，那么我的程序也要进行相应的修改，
如果数据库不小心挂掉了，则同时也意味着程序的不可用，而对于很多应用来说，并不能接受；引入Mycat中间件能很好地对程序和数据库进行解耦，这样，程序只需关注数据库中间件的地址，而无需知晓底层数据库是如何
提供服务的，大量的通用数据聚合、事务、数据源切换等工作都由中间件来处理；Mycat中间件的原理是对数据进行分片处理，从原有的一个库，被切分为多个分片数据库，所有的分片数据库集群构成完成的数据库存储，
有点类似磁盘阵列中的RAID0.
Mycat安装
1.创建表结构
CREATE DATABASE IF NOT EXISTS `weibo_simple`; -- ------------------------------------ -- Table structure for `t_users` 用户表 -- ------------------------------------ DROP TABLE IF EXISTS `t_users`; CREATE TABLE `t_users` ( `user_id` varchar(64) NOT NULL COMMENT '注册用户ID', `user_email` varchar(64) NOT NULL COMMENT '注册用户邮箱', `user_password` varchar(64) NOT NULL COMMENT '注册用户密码', `user_nikename` varchar(64) NOT NULL COMMENT '注册用户昵称', `user_creatime` datetime NOT NULL COMMENT '注册时间', `user_status` tinyint(1) NOT NULL COMMENT '验证状态 1：已验证 0：未验证', `user_deleteflag` tinyint(1) NOT NULL COMMENT '删除标记 1：已删除 0：未删除', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- ------------------------------------- -- Table structure for `t_message`微博表 -- ------------------------------------- DROP TABLE IF EXISTS `t_message`; CREATE TABLE `t_message` ( `messages_id` varchar(64) NOT NULL COMMENT '微博ID', `user_id` varchar(64) NOT NULL COMMENT '发表用户', `messages_info` varchar(255) DEFAULT NULL COMMENT '微博内容', `messages_time` datetime DEFAULT NULL COMMENT '发布时间', `messages_commentnum` int(12) DEFAULT NULL COMMENT '评论次数', `message_deleteflag` tinyint(1) NOT NULL COMMENT '删除标记 1：已删除 0：未删除', `message_viewnum` int(12) DEFAULT NULL COMMENT '被浏览量', PRIMARY KEY (`messages_id`), KEY `user_id` (`user_id`), CONSTRAINT `t_message_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `t_users` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
2.配置server.xml
<!-- 添加user --> <user name="mycat"> <property name="password">mycat</property> <property name="schemas">mycat</property> </user> <!-- 添加user --> <user name="mycat_read"> <property name="password">mycat_red</property> <property name="schemas">mycat</property> <property name="readOnly">true</property> </user>
3.配置schema.xml
<?xml version="1.0"?> <!DOCTYPE mycat:schema SYSTEM "schema.dtd"> <mycat:schema xmlns:mycat="http://org.opencloudb/"> <!-- 与server.xml中user的schemas名一致 --> <schema name="mycat" checkSQLschema="true" sqlMaxLimit="100"> <table name="t_users" primaryKey="user_id" dataNode="dn1" rule="rule1"/> <table name="t_message" type="global" primaryKey="messages_id" dataNode="dn1" /> </schema> <dataNode name="dn1" dataHost="jdbchost" database="weibo_simple" /> <dataHost name="jdbchost" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100"> <heartbeat>select user()</heartbeat> <writeHost host="hostMaster" url="172.27.185.1:3306" user="root" password="root"> </writeHost> <writeHost host="hostSlave" url="172.27.185.2:3306" user="root" password="root"/> </dataHost> </mycat:schema>
4.配置rule.xml文件
<?xml version="1.0" encoding="UTF-8"?> <!-- - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. --> <!DOCTYPE mycat:rule SYSTEM "rule.dtd"> <mycat:rule xmlns:mycat="http://org.opencloudb/"> <tableRule name="rule1"> <rule> <columns>user_id</columns> <algorithm>func1</algorithm> </rule> </tableRule> <function name="func1" class="org.opencloudb.route.function.AutoPartitionByLong"> <property name="mapFile">autopartition-long.txt</property> </function> </mycat:rule>
5.为了更好地定位错误，修改log4j.xml
<level value="debug" /> // 双击startup_nowrap.bat开始启动
其他数据库
作为一名后端开发人员，务必精通作为存储核心的MySQL或SQL Server，也要积极关注NoSQL数据库，他们已经足够成熟并被广泛采用，能解决特定场景下的性能瓶颈。
| 分类 |
数据库 |
特性 |
| 键值型 |
Memcache |
用于内容缓存，大量数据的高访问负载 |
| 键值型 |
[Redis](https://redis.io/) |
用于内容缓存，比Memcache支持更多的数据类型，并能持久化数据 |
| 列式存储 |
HBase |
Hadoop体系的核心数据库，海量结构化数据存储，大数据必备。 |
| 文档型 |
MongoDb |
知名文档型数据库，也可以用于缓存 |
| 文档型 |
CouchDB |
Apache的开源项目，专注于易用性，支持REST API |
| 文档型 |
SequoiaDB |
国内知名文档型数据库 |
| 图形 |
Neo4J |
用于社交网络构建关系图谱，推荐系统等 |
常见命令
1.给账号分配权限 grant all privileges on *.* to 'root'@'172.27.185.1' identified by 'root'; 2.查询服务器server_id SHOW VARIABLES LIKE 'server_id'