代码拉取完成，页面将自动刷新
同步操作将从 Java精选/Ebooks 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
RANGE分区： 基于属于一个给定连续区间的列值，把多行分配给分区。这种模式允许将数据划分不同范围。例如可以将一个表通过年份划分成若干个分区。
LIST分区： 类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择。这种模式允许系统通过预定义的列表的值来对数据进行分割。按照List中的值分区，与RANGE的区别是，range分区的区间范围值是连续的。
HASH分区： 基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算。这中模式允许通过对表的一个或多个列的HashKey进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区。例如可以建立一个对表主键进行分区的表。
KEY分区： Hash模式的一种延伸，类似于按HASH分区，区别在于KEY分区只支持计算一列或多列且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值。
如果是单机的话，选择自增ID；如果是分布式系统，优先考虑UUID，但是建议公司自身有一套分布式唯一ID生产方案。
自增ID：数据存储空间小，查询效率高。但是如果数据量过大,会超出自增长的值范围，多库合并，也有可能有问题。
UUiD：适合大量数据的插入和更新操作，但是它无序的，插入数据效率慢，占用空间大。
1、重用SQL语句；
2、简化复杂的SQL操作。
3、使用表的组成部分而不是整个表；
4、保护数据；
5、更改数据格式和表示。视图可返回与底层表的表示和格式不同的数据。
方式一： 如果id是连续的，可以这样，返回上次查询的最大记录(偏移量)，再往下limit
select id，name from employee where id>1000000 limit 10
方式二： 在业务允许的情况下限制页数：
建议跟业务讨论，有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。
方式三： order by + 索引（id为索引）
select id，name from employee order by id limit 1000000,10
方式四： 利用延迟关联或者子查询优化超多分页场景。（先快速定位需要获取的id段，然后再关联）
SELECT a.* FROM employee a, (select id from employee where 条件 LIMIT 1000000,10 ) b where a.id = b.id
触发器是一种特殊类型的存储过程，当使用下面的一种或多种数据修改操作在指定表中对数据进行修改时，触发器会生效：UPDATE、INSERT 或 DELETE。
触发器可以查询其它表，且可以包含复杂的 SQL 语句。它们主要用于强制复杂的业务规则或要求。例如，可以控制是否允许基于顾客的当前帐户状态插入定单。
触发器有助于强制引用完整性，以便在添加、更新或删除表中的行时保留表之间已定义的关系。然而，强制引用完整性的最好方法是在相关表中定义主键和外键约束。如果使用数据库关系图，则可以在表之间创建关系以自动创建外键约束。
要安全的修改同一行数据，就要保证一个线程在修改时其它线程无法更新这行记录。一般有悲观锁和乐观锁两种方案。
使用悲观锁
悲观锁思想是当前线程要进来修改数据时，别的线程都得拒之门外，比如可以使用如下SQL语句。
select * from jingxuan where id=736 for update
以上这条sql语句会锁定了User表中所有符合检索条件（id=736）的记录。本次事务提交之前，别的线程都无法修改这些记录。
使用乐观锁
乐观锁思想是有线程过来，先放过去修改，如果看到别的线程没修改过，就可以修改成功，如果别的线程修改过，就修改失败或者重试。
实现方式：乐观锁一般会使用版本号机制或CAS算法实现。
1、B+的磁盘读写代价更低。
B+的内部结点并没有指向关键字具体信息的指针，因此其内部结点相对B树更小。
如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。
2、B+-tree的查询效率更加稳定。
由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
B+树是一个平衡的多叉树，从根节点到每个叶子节点的高度差值不超过1，而且同层级的节点间有指针相互链接，是有序的。
哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检索时不需要类似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可,是无序的。
监控数据库的工具有很多，例如zabbix、lepus等，比较常用的是zabbix。
1、字段名及字段配制合理性
剔除关系不密切的字段；
字段命名要有规则及相对应的含义（不要一部分英文，一部分拼音，还有类似a.b.c这样不明含义的字段）；
字段命名尽量不要使用缩写（大多数缩写都不能明确字段含义）；
字段不要大小写混用（想要具有可读性，多个英文单词可使用下划线形式连接）；
字段名不要使用保留字或者关键字；
保持字段名和类型的一致性；
慎重选择数字类型；
给文本字段留足余量。
2、系统特殊字段处理及建成后建议
添加删除标记（例如操作人、删除时间）；
建立版本机制。
3、表结构合理性配置
多型字段的处理，就是表中是否存在字段能够分解成更小独立的几部分（例如：人可以分为男人和女人）；
多值字段的处理，可以将表分为三张表，这样使得检索和排序更加有调理，且保证数据的完整性！
4、其它建议
对于大数据字段，独立表进行存储，以便影响性能（例如：简介字段）；
使用varchar类型代替char，因为varchar会动态分配长度，char指定长度是固定的；
给表创建主键，对于没有主键的表，在查询和索引定义上有一定的影响；
避免表字段运行为null，建议设置默认值（例如：int类型设置默认值为0）在索引查询上，效率立显；
建立索引，最好建立在唯一和非空的字段上，建立太多的索引对后期插入、更新都存在一定的影响（考虑实际情况来创建）。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
