mysql数据库可靠性分析

mysql数据库有undo空间5种mysql做可靠性分析的方案：1．MySQL Clustering(ndb-cluster stogare)简介：MySQL公司以存储引擎方式提供的高可靠性方案，是事务安全的，实时复制数据，可用于需要高可靠性及负载均衡的场合。该方案至少需要三个节点服务器才能达到较好的效果。成本：节点服务器对RAM的需求很大，与数据库大小呈线性比例；最好使用千兆以太网络；还需要使用Dolphin公司提供的昂贵的SCI卡。优点：可用于负载均衡场合；可用于高可靠性场合；高伸缩性；真正的数据库冗余；容易维护。缺点：随着数据库的变大，对RAM的需求变得更大，因此成本很高；速度：几乎 比典型的单独服务器（无千兆以太网，无SCI卡，存储引擎相关的限制少）慢10倍。应用场合：冗余，高可靠性，负载均衡2. MySQL / GFS-GNBD/ HA (Active/Passive)简介：如果多个MySQL服务器使用共享硬盘作为数据存储，此方案如何？GFS/GNBD可以提供所需的共享硬盘。GFS是事务安全的文件系统。同一时刻你可以让一个MySQL使用共享数据。成本：最多n台高性能服务器的成本，其中一个激活的，其他作为备份服务器。优点：高可靠性某种程度的冗余按照高可靠性进行伸缩缺点：没有负载均衡没有保证的冗余无法对写 *** 作进行伸缩速度：单独服务器的2倍。对读 *** 作支持得较好。应用场合：需要高可靠性的、读 *** 作密集型的应用3. MySQL / DRBD / HA (Active/Passive)简介：如果多个MySQL服务器使用共享硬盘作为数据存储，此方案如何？DRBD可以提供这样的共享硬盘。DRBD可以被设置成事务安全的。同一时刻你可以让一个MySQL使用共享数据。成本：最多n台高性能服务器的成本，其中一个激活的，而其他则作为备份服务器。优点：高可靠性；一定程度的冗余；以高可靠性名义来看是可伸缩的。缺点：没有负载均衡没有保证的冗余在写负载方面没有伸缩性速度：在读写方面相当于单独服务器应用场合需要高可靠性、读 *** 作密集型的应用4. MySQL Write Master / Multiple MySQL Read Slaves (Active/Active)简介：考虑不同的读、写DB数据库连接的情况。可以使用一台主服务器用于写 *** 作，而采用n台从服务器用于读 *** 作。成本：最多1台高性能写服务器，n台读服务器的成本优点:读 *** 作的高可靠性；读 *** 作的负载均衡；在读 *** 作负载均衡方面是可伸缩的。缺点：无写 *** 作的高可靠性；无写 *** 作的负载均衡；在写 *** 作方面无伸缩性；速度：同单独服务器；在读 *** 作方面支持得较好应用场合读 *** 作密集型的、需要高可靠性和负载均衡的应用。5. Standalone MySQL Servers(Functionally separated) (Active)多台功能分离的单独服务器，没有高可靠性、负载均衡能力，明显缺点太多，不予考虑。

作为一名程序员，在求职面试时，不知你有没有遇到类似这样的问题。

张工是一名java程序员，最近到一家软件公司应聘软件开发岗位，面试官问了他关于MySql索引这样的一个问题。

对于这个问题张工之前在做项目时也曾遇到，那时候字段明明是加了索引，可不明白为什么还是很慢。后加上引号就正常了，为了赶项目进度，张工也没有再去留意。

现在面试官突然这么一问，张工也说不出个所以然来。

面试官让他回去等通知。

我们知道MySql索引可以加快数据检索速度，这也是使用的索引的最主要原因。但有时候使用不当就会遇到索引失效问题，譬如在MySQL字符串类型查询时不加引号索引会失效，是因为MySQL内部进行了隐式转换。

那为什么会发生隐式转换？又是怎么转换的呢？

今天我们来聊聊关于MySql索引失效的话题。

先来看看一般导致索引失效的有哪些？

如果一张表的索引有多个，要遵守最佳左前缀法则，即查询从索引的最左前列开始并且不跳过索引中的列。

用户表tb_user字段 id，name，age，sex

创建索引为idx_user_name

执行语句：

这时候就会导致索引失效

在索引列上做加工 *** 作，查询时会导致索引失效，从而导致全表扫描。所以，建议不要在索引列上做任何 *** 作。

举个例子，例如订单表tb_order有个索引是dt（日期）， 字段数据存放的格式是这样的2021-12-10 这样的，如果有个需求需要根据dt，格式是20220207这样的来查询，这时候就不要对dt进行格式转换了，

这样索引就失效了。

而是应该对 20220207做格式处理

这样dt索引才不会失效。

例如我们在订单表tb_order建立了索引idx_order_id，order_id字段类型为varchar

在查询时如果使用where order_id= 20220207123654100，这样的查询方式会直接造成索引失效。

要让索引生效，正确的用法为

假如有张用户表tb_user，创建的索引为idx_user_name_age_sex_phone 其中name、age、sex都加了索引。

执行语句

上面这条sql语句只会命中name和age索引，sex索引会失效，复合索引失效需要查看key_len的长度。

再来看一个例子：

从这两条SQL执行的结果我们可以看出，执行第一条SQL没有使用到索引，而执行第二条SQL时使用到了索引。这是为什么呢？

我们需要先了解下mysql索引优化器工作的原理。选择索引是优化器工作，优化器工作有自己的一套规则，如果等号两边的数据类型不一致，则会发生隐式转换。

基于这条规则，我们回过头看看

这条SQL语句执行时就会变为

由于对索引列进行了函数 *** 作，所以才导致索引失效，从而全表扫描了。

那么问题来了，细心的你不知有没有留意到为什么是把左侧的列转为int类型，而不是把右侧的值转成字符串类型呢？

什么情况下把数字转为字符串，什么情况下把字符串转为数字，优化器它是根据什么规则来进行判断的？其实规则也并不复杂。

根据这个规则，我们再回过头看看之前的查询语句

select '12345678936' = 12345678936

返回1 所以这时候就把左侧的列值12345678936转成数字。

关于MySql索引失效的问题先简单写到这，建议平时在做项目时还是要多了解下原理，如果你了解其背后的原理，求职面试时和面试官交流起来就会很舒服了，相信能为这次面试加分，提高被录用的概率。

为什么MySQL字符串类型查询时不加引号索引会失效？这是因为要查询的字符串字段没有加引号时，MySQL内部进行了隐式转换，此次查询会导致全表扫描，所以慢了。

总结：

在索引列上进行了函数 *** 作，MySQL内部会进行了隐式转换，导致索引失效，从而产生全表扫描。

由于笔者知识及水平有限,文中错漏之处在所难免,如有不足之处，欢迎交流。

拓展

索引创建

1、主键索引：

2、唯一索引：

3、普通索引：

4、全文索引：

alter table table_name add fulltext (column)

5、联合索引：

索引删除

对于游戏币等代币，一般存储为int类型是可行的。问题在于越界，int类型长度为11位。

在存储人民币相关的金额的时候，则只能存储到9长度的人民币，也就是说，最大只能存储999999999，不到10亿的数值，如果业务增长很快的话，就会给自己留下隐患。

Decimal：Decimal为专门为财务相关问题设计的数据类型。

DECIMAL从MySQL5.1引入，列的声明语法是DECIMAL(M,D)。在MySQL5.1中，参量的取值范围如下：M是数字的最大数（精度）。其范围为1～65（在较旧的MySQL版本中，允许的范围是1～254），M的默认值是10。

D是小数点右侧数字的数目（标度）。其范围是0～30，但不得超过M。说明：float占4个字节，double占8个字节，decimail(M,D)占M+2个字节。

如DECIMAL(5,2)的最大值为9999.99，因为有7个字节可用。能够解决数据的范围和精度的问题。

扩展资料

MySQL数据类型DECIMAL用法：

MySQL DECIMAL数据类型用于在数据库中存储精确的数值。我们经常将DECIMAL数据类型用于保留准确精确度的列，例如会计系统中的货币数据。

要定义数据类型为DECIMAL的列，请使用以下语法：column_name  DECIMAL(P,D)

在上面的语法中：

P是表示有效数字数的精度。 P范围为1〜65。

D是表示小数点后的位数。 D的范围是0~30。MySQL要求D小于或等于(<=)P。

DECIMAL(P，D)表示列可以存储D位小数的P位数。十进制列的实际范围取决于精度和刻度。

与INT数据类型一样，DECIMAL类型也具有UNSIGNED和ZEROFILL属性。如果使用UNSIGNED属性，则DECIMALUNSIGNED的列将不接受负值。

如果使用ZEROFILL，MySQL将把显示值填充到0以显示由列定义指定的宽度。另外，如果我们对DECIMAL列使用ZEROFILL，MySQL将自动将UNSIGNED属性添加到列。

---