MYSQL中的int(11)到底代表什么意思?

对于int类型的一些基础知识其实上图已经说的很明白了,在这里想讨论下常用的int(11)代表什么意思,很长时间以来我都以为这代表着限制int的长度为11位,直到有天看到篇文章才明白,11代表的并不是长度,而是字符的显示宽度,在字段类型为int时,无论你显示宽度设置为多少,int类型能存储的最大值和最小值永远都是固定的...

分类至 MySQL
0条评论

MYSQL:int类型升级到bigint,对PHP开发语言影响

因为业务增长,原有的unsigned int已经不够使用,需要升级到unsigned bigint。

MYSQL整数支持的范围:https://dev.mysql.com/doc/refman/5.7/en/integer-types.html

Type Storage Minimum Value Maximum Value
  (Bytes) (Signed/Unsigned) (Signed/Unsigned)
TINYINT 1 -128 127
    0 255
SMALLINT 2 -32768 32767
    0 65535
MEDIUMINT 3 -8388608 8388607
    0 16777215
INT 4 -2147483648 2147483647
    0 4294967295
BIGINT 8 -9223372036854775808 9223372036854775807
    0 18446744073709551615

可以看到bigint支持的数量级非常大。虽然mysql字段类型调整了,但是我们的开发语言是否支持呢?

 

分类至 MySQL
0条评论

mysql字段定义不要用null的分析

(1) java的null

null是一个让人头疼的问题,比如java中的NullPointerException。为了避免猝不及防的空指针,需要小心翼翼地各种if判断,麻烦又臃肿.

为此有很多的开源包都有诸多处理

common lang3的StringUtils.isBlank();   CollectionUtils.isEmpty();

guava的Optional

甚至java8也引入了Optional来避免这一问题(和guava的大同小异,用法稍有一点点变化)

(2) mysql的null为什么横行滥用

(a) 创建不规范  null是创建数据表时候默认的,一些mysql客户端的自动生成表语句里面可能也没有not null的指定。

(b) 错误认识    会有人觉得not null需要更多的空间

(c) 图省事       null在开发中不用判断插入数据,写sql更方便

……

 

分类至 MySQL
0条评论

MySQL 5.7:聊聊sql_mode

1、sql_mode=only_full_group_by 导致的语法错误问题 MySQLSyntaxErrorException

Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'db.table.id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

该问题是因为MySQL Server 默认开启了 sql_mode=only_full_group_by 模式,此模式要求 group by 字段必须出现在查询项中(select),否则就会报出该错误。解决的方式也很简单见(5),借着这个异常问题,借机在本文就来学习一下,MySQL 5.7 中的 sql_mode。

2、简介

MySQL服务器可以在不同的SQL模式下运行,并且可以针对不同的客户端以不同的方式应用这些模式,具体取决于sql_mode系统变量的值。可以设置全局SQL模式以匹配站点服务器的操作要求,每个应用程序也可以设置会话级别的SQL模式来满足自己的需求。

sql_mode 模式会影响MYSQL语法及执行数据的验证检查。这使得在不同环境中使用MySQL以及将MySQL与其他数据库服务器一起使用变得更加容易。

3、MySQL 5.7 和 MySQL 5.8 中默认的sql_mode

3.1、查询sql_mode的方式

查询全局sql_mode
SELECT @@GLOBAL.sql_mode;
查询当前会话sql_mode
SELECT @@SESSION.sql_mode;

3.2、MySQL 5.7中的默认SQL模式:

ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION

MySQL 5.7.5 中默认SQL模式添加了 ONLY_FULL_GROUP_BY和STRICT_TRANS_TABLES

MySQL 5.7.7 中默认SQL模式添加了 NO_AUTO_CREATE_USER

MySQL 5.7.8 中默认SQL模式添加了 ERROR_FOR_DIVISION_BY_ZERO,NO_ZERO_DATE 和 NO_ZERO_IN_DATE

...

分类至 MySQL
0条评论

MySQL的四种事务隔离级别

一、事务的基本要素(ACID)
  1、原子性(Atomicity):事务开始后所有操作,要么全部做完,要么全部不做,不可能停滞在中间环节。事务执行过程中出错,会回滚到事务开始前的状态,所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体,就像化学中学过的原子,是物质构成的基本单位。
  2、一致性(Consistency):事务开始前和结束后,数据库的完整性约束没有被破坏 。比如A向B转账,不可能A扣了钱,B却没收到。
  3、隔离性(Isolation):同一时间,只允许一个事务请求同一数据,不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱,在A取钱的过程结束前,B不能向这张卡转账。
  4、持久性(Durability):事务完成后,事务对数据库的所有更新将被保存到数据库,不能回滚。
二、事务的并发问题 ……
三、MySQL事务隔离级别 ……

分类至 MySQL
0条评论

MySQL 5.7 完美的分布式事务支持

分布式事务通常采用2PC协议,全称Two Phase Commitment Protocol。该协议主要为了解决在分布式数据库场景下,所有节点间数据一致性的问题。在分布式事务环境下,事务的提交会变得相对比较复杂,因为多个节点的存在,可能存在部分节点提交失败的情况,即事务的ACID特性需要在各个数据库实例中保证。总而言之,在分布式提交时,只要发生一个节点提交失败,则所有的节点都不能提交,只有当所有节点都能提交时,整个分布式事务才允许被提交。

分布式事务通过2PC协议将提交分成两个阶段:
prepare;
commit/rollback

第一阶段的prepare只是用来询问每个节点事务是否能提交,只有当得到所有节点的“许可”的情况下,第二阶段的commit才能进行,否则就rollback。需要注意的是:prepare成功的事务,则必须全部提交。

分类至 MySQL
0条评论

浅谈MySQL中优化sql语句查询常用的30种方法

本篇文章是对MySQL中优化sql语句查询常用的30种方法进行了详细的分析介绍,需要的朋友参考下。
1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 
2.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。 
3.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: 
select id from t where num is null 
可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: 
select id from t where num=0 
...

分类至 MySQL
1条评论

MySQL大数据量分页查询方法及其优化

方法1:直接使用数据库提供的SQL语句limit
方法2:建立主键或唯一索引, 利用索引(假设每页10条)
方法3:基于索引再排序
方法4:基于索引使用prepare(第一个问号表示pageNum,第二个?表示每页元组数)
方法5:利用MySQL支持ORDER操作可以利用索引快速定位部分元组,避免全表扫描
方法6:利用"子查询/连接+索引"快速定位元组的位置,然后再读取元组. 道理同方法5

分类至 MySQL
0条评论

MySQL EXPLAIN 命令详解

在工作中,我们用于捕捉性能问题最常用的就是打开慢查询,定位执行效率差的SQL,那么当我们定位到一个SQL以后还不算完事,我们还需要知道该SQL的执行计划,比如是全表扫描,还是索引扫描,这些都需要通过EXPLAIN去完成。EXPLAIN命令是查看优化器如何决定执行查询的主要方法。可以帮助我们深入了解MySQL的基于开销的优化器,还可以获得很多可能被优化器考虑到的访问策略的细节,以及当运行SQL语句时哪种策略预计会被优化器采用。需要注意的是,生成的QEP并不确定,它可能会根据很多因素发生改变。MySQL不会将一个QEP和某个给定查询绑定,QEP将由SQL语句每次执行时的实际情况确定,即便使用存储过程也是如此。尽管在存储过程中SQL语句都是预先解析过的,但QEP仍然会在每次调用存储过程的时候才被确定。

分类至 MySQL
0条评论