1.left join 基本用法

mysql left join 语句格式

A LEFT JOIN B ON 条件表达式

left join 是以A表为基础，A表即左表，B表即右表。

左表(A)的记录会全部显示，而右表(B)只会显示符合条件表达式的记录，如果在右表(B)中没有符合条件的记录，则记录不足的地方为NULL。

2.left join 右表数据不唯一解决方法

但如果B表符合条件的记录数大于1条，就会出现1:n的情况，这样left join后的结果，记录数会多于A表的记录数。

含 0条评论

数据库在通过连接两张或多张表来返回记录时，都会生成一张中间的临时表，然后再将这张临时表返回给用户。

在使用 left join 时，on 和 where 条件的区别如下：

1、on 条件是在生成临时表时使用的条件，它不管 on 中的条件是否为真，都会返回左边表中的记录。

2、where 条件是在临时表生成好后，再对临时表进行过滤的条件。这时已经没有 left join 的含义（必须返回左边表的记录）了，条件不为真的就全部过滤掉。

 

含 0条评论

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

含 0条评论

因为业务增长，原有的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字段类型调整了，但是我们的开发语言是否支持呢？

 

含 0条评论

int
1. 占用4个字节
2. 建立索引之后，查询速度快
3. 条件范围搜索可以使用使用between
4. 不能使用mysql提供的时间函数
结论：适合需要进行大量时间范围查询的数据表

datetime
……

timestamp
……

含 0条评论

(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更方便

……

 

含 0条评论

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

…

含 0条评论

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

含 0条评论

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

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

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

含 0条评论

本篇文章是对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 
...

含 1条评论