有关各种数据库知识及学习心得
1月19
mysql分区后每个分区成了独立的文件,虽然从逻辑上还是一张表其实已经分成了多张独立的表,从“information_schema.INNODB_SYS_TABLES”系统表可以看到每个分区都存在独立的TABLE_ID,由于Innodb数据和索引都是保存在".ibd"文件当中(从INNODB_SYS_INDEXES系统表中也可以得到每个索引都是对应各自的分区(primary key和unique也不例外)),所以分区表的索引也是随着各个分区单独存储。

在INNODB_SYS_INDEXES系统表中type代表索引的类型;

0:一般的索引,

1:(GEN_CLUST_INDEX)不存在主键索引的表,会自动生成一个6个字节的标示值,

2:unique索引,

3:primary索引;

所以当我们在分区表中创建索引时其实也是在每个分区中创建索引,每个分区维护各自的索引(其实也就是local index);对于一般的索引(非主键或者唯一)没什么问题由于索引树中只保留了索引key和主键key(如果存在主键则是主键的key否则就是系统自动生成的6个的key)不受分区的影响;但是如果表中存在主键就不一样了,虽然在每个分区文件中都存在主键索引但是主键索引需要保证全局的唯一性就是所有分区中的主键的值都必须唯一(唯一键也是一样的道理),所以在创建分区时如果表中存在主键或者唯一键那么分区列必须包含主键或者唯一键的部分或者全部列(全部列还好理解,部分列也可以个人猜测是为了各个分区和主键建立关系),由于需要保证全局性又要保证插入数据更新数据到具体的分区所以就需要将分区和主键建立关系,由于通过一般的索引进行查找其它非索引字段需要通过主键如果主键不能保证全局唯一性的话那么就需要去每个分区查找了,这样性能可想而知。

To enforce the uniqueness we only allow mapping of each unique/primary key value to one partition.If we removed this limitation it would mean that for every insert/update we need to check in every partition to verify that it is unique. Also PK-only lookups would need to look into every partition.

索引方式:
性能依次降低
1.主键分区

主键分区即字段是主键同时也是分区字段,性能最好

2. 部分主键+分区索引

使用组合主键里面的部分字段作为分区字段,同时将分区字段建索引(见下面详细说明)

3.分区索引

没有主键,只有分区字段且分区字段建索引

4.分区+分区字段没有索引

只建了分区,但是分区字段没有建索引

总结

因为每一个表都需要有主键这样可以减少很多锁的问题,由于上面讲过主键需要解决全局唯一性并且在插入和更新时可以不需要去扫描全部分区,造成主键和分区列必须存在关系;所以最好的分区效果是使用主键作为分区字段其次是使用部分主键作为分区字段且创建分区字段的索引,其它分区方式都建议不采取。


MYSQL的分区字段,必须包含在主键字段内
在对表进行分区时,如果分区字段没有包含在主键字段内,如表A的主键为ID,分区字段为createtime ,按时间范围分区,代码如下:

CREATE TABLE T1 (
     id int(8) NOT NULL AUTO_INCREMENT,
     createtime datetime NOT NULL,
      PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8
PARTITION BY RANGE(TO_DAYS (createtime))
(
PARTITION p0 VALUES LESS THAN (TO_DAYS('2010-04-15')),
PARTITION p1 VALUES LESS THAN (TO_DAYS('2010-05-01')),
PARTITION p2 VALUES LESS THAN (TO_DAYS('2010-05-15')),
PARTITION p3 VALUES LESS THAN (TO_DAYS('2010-05-31')),
PARTITION p4 VALUES LESS THAN (TO_DAYS('2010-06-15')),
PARTITION p19 VALUES LESS ThAN  MAXVALUE);
复制代码
错误提示:#1503

MySQL主键的限制,每一个分区表中的公式中的列,必须在主键/unique key 中包括,在MYSQL的官方文档里是这么说明的
18.5.1. Partitioning Keys, Primary Keys, and Unique Keys
This section discusses the relationship of partitioning keys with primary keys and unique keys. The rule governing this relationship can be expressed as follows: All columns used in the partitioning expression for a partitioned table must be part of every unique key that the table may have.

In other words,every unique key on the table must use every columnin the table's partitioning expression. (This also includes the table's primary key, since it is by definition a unique key. This particular case is discussed later in this section.) For example, each of the following table creation statements is invalid:
分区字段必须包含在主键字段内,至于为什么MYSQL会这样考虑,我觉得是这样的:为了确保主键的效率。否则同一主键区的东西一个在A分区,一个在B分区,显然会比较麻烦。

下面讨论解决办法,毕竟在一张表里,日期做主键的还是不常见。
方法1:
顺应MYSQL的要求,就把分区字段加入到主键中,组成复合主键
CREATE TABLE T1 (
     id int(8) NOT NULL AUTO_INCREMENT,
     createtime datetime NOT NULL,
      PRIMARY KEY (id,createtime)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8
PARTITION BY RANGE(TO_DAYS (createtime))
(
PARTITION p0 VALUES LESS THAN (TO_DAYS('2010-04-15')),
PARTITION p1 VALUES LESS THAN (TO_DAYS('2010-05-01')),
PARTITION p2 VALUES LESS THAN (TO_DAYS('2010-05-15')),
PARTITION p3 VALUES LESS THAN (TO_DAYS('2010-05-31')),
PARTITION p4 VALUES LESS THAN (TO_DAYS('2010-06-15')),
PARTITION p19 VALUES LESS ThAN  MAXVALUE);
测试通过,分区成功。
1月18
大家都知道删除分区的语句如下:
ALTER TABLE '表名' DROP PARTITION '分区名' ; 但是这样的话只能一个个分区去删除,而且删除分区同时会把数据也给删除掉了,那么mysql删除表的所有分区如何操作呢?
只要使用ALTER TABLE 表名 REMOVE PARTITIONING 就可以删除所有分区,但数据不会被删除。

查询指定表的分区信息以及每个分区的行数
SELECT PARTITION_NAME,TABLE_ROWS
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_NAME = '表名';

SELECT
  PARTITION_NAME,PARTITION_DESCRIPTION,
FROM_UNIXTIME(PARTITION_DESCRIPTION,'%Y-%m-%d') EXPIRYDATE,TABLE_ROWS
FROM
INFORMATION_SCHEMA.PARTITIONS where TABLE_NAME ='表名';
1月18
今天主要介绍下面这几个错误:

ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning

ERROR 1503 (HY000): A UNIQUE INDEX must include all columns in the table's partitioning function

主键必须包括表的分区函数中的所有列,一个惟一的索引必须包括表的分区函数中的所有列,是不是不太好理解意思

其实就是这么个意思:表上的每一个唯一性索引必须用于分区表的表达式上(其中包括主键索引)

下面我来举几个例子:


CREATE TABLE t1 (  
     id INT NOT NULL,  
     aid DATE NOT NULL,  
     bid INT NOT NULL,  
     PRIMARY KEY (id)  
)  
PARTITION BY KEY(bid)  
PARTITIONS 10;
[Err] 1503 - A PRIMARY KEY must include all columns in the table's partitioning function


CREATE TABLE t1 (  
     id INT NOT NULL,  
     aid DATE NOT NULL,  
     bid INT NOT NULL,    
     UNIQUE KEY (id)  
)  
PARTITION BY KEY(bid)  
PARTITIONS 10;
[Err] 1503 - A PRIMARY KEY must include all columns in the table's partitioning function


CREATE TABLE t1 (  
     id INT NOT NULL,  
     aid DATE NOT NULL,  
     bid INT NOT NULL,  
     PRIMARY KEY (id,bid)  
)  
PARTITION BY KEY(bid)  
PARTITIONS 10;
Query OK, 0 rows affected (0.535 sec)

12月29
一、所有库在同一节点上
 当业务垂直拆分出很多业务库的时候,如果都部署在同一个源上(同一个机器节点上),那么这种情况是最好办的,直接库名+表名 join就可以。

二、不在一个节点

当不同的库来自不同的节点,那么就没办法直接join查询了,有以下方式和思路:
1.全局表
  所谓全局表,就是有可能系统中所有模块都可能会依赖到的一些表。比较类似我们理解的“数据字典”。为了避免跨库join查询,我们可以将这类表在其他每个数据库中均保存一份。同时,这类数据通常也很少发生修改(甚至几乎不会),
  所以也不用太担心“一致性”问 题。

2.字段冗余
  这是一种典型的反范式设计,在互联网行业中比较常见,通常是为了性能来避免join查询。字段冗余能带来便利,是一种“空间换时间”的体现。但其适用场景也比较有限,比较适合依赖字段较少的情况。

  最复杂的还是数据一致性问题,这点很难保证,可以借助数据库中的触发器或者在业务代码层面去保证。当然,也需要结合实际业务场景来看一致性的要求。


3.数据同步
  定时A库中的tab_a表和B库中tbl_b有关联,可以定时将指定的表做同步。当然,同步本来会对数据库带来一定的影响,需要性能影响和数据时效性中取得一个平衡。这样来避免复杂的跨库查询。笔者曾经在项目中是通过ETL工具来实施的。


4.第三方插件
    1.cobar
    2.MyCAT
    3.shardding-jdbc
12月7
一、前言
MySQL 支持由 RFC 7159 定义的原生JSON 数据类型,该数据类型可以有效访问 JSON(JavaScript Object Notation)中的元素数据。与将JSON 格式的字符串存储为单个字符串类型相比,JSON 数据类型具有以下优势:

自动验证存储在JSON列中的JSON数据格式。无效格式会报错。
优化的存储格式。存储在JSON列中的JSON文档被转换为允许快速读取访问文档元素的内部格式。内部是以二进制格式存储JSON数据。
对JSON文档元素的快速读取访问。当服务器读取JSON文档时,不需要重新解析文本获取该值。通过key或数组索引直接查找子对象或嵌套值,而不需要读取整个JSON文档。
存储JSON文档所需的空间,大致与LONGBLOB或LONGTEXT相同
存储在JSON列中的任何JSON文档的大小都仅限于设置的系统变量max_allowed_packet的值
MySQL 8.0.13之前,JSON列不能有非null的默认值。
在 MySQL 8.0 中,优化器可以对 JSON 列执行部分就地更新,而不是删除旧JSON串并将新串完整地写入列。
MYSQL 8.0,除了提供JSON 数据类型,还有一组 SQL 函数可用于操作 JSON 的值,例如创建JSON对象、增删改查JSON数据中的某个元素。

二、常用JSON函数
首先,创建表列时候,列要设置为JSON类型:

1
CREATE TABLE t1 (content JSON);
插入数据,可以像插入varchar类型的数据一样,把json串添加单引号进行插入:

1
INSERT INTO t1 VALUES('{"key1": "value1", "key2": "value2"}');
当然mysql也提供了创建JSON对象的函数:

1
INSERT INTO t1 VALUES(JSON_OBJECT("key1","value1","key2","value2"));
使用JSON_EXTRACT函数查询JSON类型数据中某个元素的值:


mysql> SELECT  JSON_EXTRACT(content,"$.key1") from t1;

+--------------------------------+
| JSON_EXTRACT(content,"$.key1") |
+--------------------------------+
| "value1"                       |
| "value1"                       |
+--------------------------------+
2 rows in set (0.00 sec)
lamba表达式风格查询:


mysql> SELECT content->"$.key1" from t1;
+-------------------+
| content->"$.key1" |
+-------------------+
| "value1"          |
| "value1"          |
+-------------------+
2 rows in set (0.00 sec)
使用JSON_SET函数更新JSON中某个元素的值,如果不存在则添加:


mysql> update t1 set content=JSON_SET(content,"$.key1",'value111');
Query OK, 2 rows affected (0.00 sec)

Rows matched: 2  Changed: 2  Warnings: 0
更多JSON类型数据操作函数,可以参考:https://dev.mysql.com/doc/refman/8.0/en/json.html

三、MyBatis中使用JSON类型及其操作函数
比如Device表里面有个JSON类型的content字段,其中含有名称为name的元素,我们来修改和查询name元素对应的值。

ExtMapper中定义修改和查询接口:

@Mapper
public interface DeviceDOExtMapper extends com.zlx.user.dal.mapper.DeviceDOMapper {
    //更新JSON串中名称为name的key的值
    int updateName(@Param("name") String name, @Param("query") DeviceQuery query);
    //查询JSON串中名称为name的key的值
    String selectName(DeviceQuery query);
}
ExtMapper.xml中定义查询sql:

<mapper namespace="com.zlx.user.dal.mapper.ext.DeviceDOExtMapper">
    <!--更新JSON串中名称为name的key的值-->
    <update id="updateName" parameterType="map">
        update device
        <set>
            <if test="name != null">
                content = JSON_SET(content, '$.name', #{name,jdbcType=VARCHAR})
            </if>
        </set>
        <if test="_parameter != null">
            <include refid="Update_By_Example_Where_Clause"/>
        </if>
    </update>

    <!--查询JSON串中名称为name的key的值-->
    <select id="selectName" parameterType="com.zlx.user.dal.model.DeviceQuery" resultType="java.lang.String">
        select
        `content`->'$.name'
        from device
        <if test="_parameter != null">
            <include refid="Example_Where_Clause"/>
        </if>
    </select>
</mapper>
总结
虽然我们实践上不建议把所有扩展字段都放到一个大字段里面。但是即使有原因一定到放,那么也建议选择JSON类型,而不是varcahr和Text类型。


参考:
https://dev.mysql.com/doc/refman/8.0/en/json.html
11月3
在mysql5.7以及之后的版本运行sql语句时,出现以下问题:
[Err] 1055 - Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column ‘information_schema.PROFILING.SEQ’ which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

出现问题的原因:
MySQL 5.7.5及以上功能依赖检测功能。如果启用了ONLY_FULL_GROUP_BY SQL模式(默认情况下),MySQL将拒绝选择列表,HAVING条件或ORDER BY列表的查询引用在GROUP BY子句中既未命名的非集合列,也不在功能上依赖于它们。(5.7.5之前,MySQL没有检测到功能依赖关系,默认情况下不启用ONLY_FULL_GROUP_BY

解决办法:
把 sql_mode中的 only_full_group_by 去掉即可
办法一:(只在当前查询页面有效,不能一次性解决问题!)

查询sql_mode: select version(), @@sql_mode;
修改为: SET sql_mode=(SELECT REPLACE(@@sql_mode,‘ONLY_FULL_GROUP_BY’,’’));
办法二: 修改 my.cnf 文件的 sql_mode (一次性解决问题)

查找 my.cnf 文件: find / -name my.cnf 或者 whereis my.cnf
获取 sql_mode字段内容: SELECT @@sql_mode;
去掉 sql_mode字段中的 only_full_group_by
编辑 my.cnf: vim /etc/my.cnf 将上一步骤的 sql_mode 字段内容添加至 my.cnf。可参考:sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
保存,重启: systemctl restart mysqld.service
11月2
一、解决方法
        如果你希望使用 group by 语句的时候避免出现 filesort, 那么只需在其后追加 order by null 语句即可, 即:    
group by ... order by null

二、说明
      1、默认情况下,mysql在使用group by之后,会产生临时表,而后进行排序(此处排序默认是快排),这会消耗大量的性能。

      2、group by本质是先分组后排序【而不是先排序后分组】。

      3、group by column 默认会按照column分组, 然后根据column升序排列;  group by column order by null 则默认按照column分组,然后根据标的主键ID升序排列
10月22
一、问题
### Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction;


现象:接口响应时间超长,耗时几十秒才返回错误提示,后台日志中出现Lock wait timeout exceeded; try restarting transaction的错误

二、原因分析
使用InnoDB表类型的时候,锁等待超过了innodb_lock_wait_timeout(默认是50s)设置的时间,所以报错

三、可能出现场景
1、在同一事务内先后对同一条数据进行插入和更新操作

2、多台服务器操作同一数据库

3、瞬时出现高并发现象,spring事务造成数据库死锁,后续操作超时抛出异常

4、事务A对记录C进行更新/删除操作的请求未commit时,事务B也对记录C进行更新/删除操作。此时,B会等A提交事务,释放行锁。当等待时间超过innodb_lock_wait_timeout设置值时,会产生“LOCK WAIT”事务。

四、解决方案
1、【治标方法】innodb_lock_wait_timeout 锁定等待时间改大

SELECT
  @@innodb_lock_wait_timeout;

innodb_lock_wait_timeout = 50

修改为
SET @@innodb_lock_wait_timeout = 500;

innodb_lock_wait_timeout = 500

缺点:全局更改,影响也是全局的,等待时间加长,容易使等待事务增多导致堆积问题。

2、【治标方法】事务信息查询

SELECT * FROM information_schema.innodb_trx

查到一个一直没有提交的只读事务(trx_state=”LOCK WAIT”),找到对应线程,执行:

kill 线程ID(trx_mysql_thread_id)

3、【治标方法】如果杀掉线程依然不能解决,可以查找执行线程耗时比较久的任务,kill掉

SELECT * from information_schema.`PROCESSLIST` WHERE Time > 1000 AND USER = 'xxx' ORDER BY TIME desc;

kill 线程ID

4、【根本解决方法!】找到锁表的事务,分析锁表原因,进行优化。

实例:司机APP进行运单签收,需要对et_waybill_info表某些记录进行更新操作。一直处于锁等待状态,直到超时报错。

经排查,发现:系统定时器定时执行任务,将所有未标识亮的已装车或签收的运单,按批次处理,如果运单装车了但长时间未上传GPS、温湿度等信息,会一直被定时器处理。数据量越积越大,队列长时间等待,对et_waybill_info表锁住没有释放,致使签收要操作et_waybill_info表无法拿到锁,进行数据操作。

临时解决方案:停掉定时器任务

根本解决方案:优化定时器

五、预防措施
1、开始事务(@transtion)指定超时时 间

例:@Transactional( rollbackFor = Exception.class , isolation = Isolation.REPEATABLE_READ, timeout = 30)

2、事务中存在批量修改、删除语句的时候,where条件尽量加索引

3、事务中存在批量修改、删除语句的时候,尽可能减少事务的执行时间

4、减少并发线程数

六、相关信息
1、innodb_lock_wait_timeout和lock_wait_timeout
innodb_lock_wait_timeout:InnoDB事务等待一个行级锁的时间最长时间(单位是秒),超过这个时间就会放弃。默认值是50秒

lock_wait_timeout:获取元数据锁的超时时间。这个适合用于除了系统表之外的所有表(mysql库之外)。

区别于innodb_lock_wait_timeout是针对dml操作的行级锁的等待时间 ,而lock_wait_timeout是数据结构ddl操作的锁的等待时间

2、事务相关表
INNODB_TRX  当前运行的所有事务



INNODB_LOCKS  当前出现的锁,查看正在锁的事务



INNODB_LOCK_WAITS  锁等待的对应关系,查看等待锁的事务



3、information_schema和performance_schema
information_schema:对数据库元数据的抽象分析,由此提供了SQL语句方式来查询数据库运行时状态,每次对infomation_schema的查询都产生对metadata的互斥访问,影响其他数据库的访问性能。这张数据表保存了MySQL服务器所有数据库的信息。如数据库名,数据库的表,表栏的数据类型与访问权限等。

performance_schema:内存型数据库,使用performance_schema存储引擎,通过事件机制将mysql服务的运行时状态采集并存储在performance_schema数据库。用于监控MySQL server在一个较低级别的运行过程中的资源消耗、资源等待等情况。

七、总结
1、当看到mysql报错时,可以根据报错的信息及错误号去分析报错原因,然后冷静分析,透过现象看本质,从根本上解决问题。少用治标不治本的方案,还可能会带来其他问题。

2、了解了mysql里几张事务相关表

3、初识information_schema和performance_schema
10月18
    最近在维护一个几年前的项目,发现供应商报价本来为decimal类型保留两位小数的数据,结果通过ifnull后变成四舍五入保小一位小数了,排查了很久才现是由于ifnull函数引起的问题。      
SELECT
        IFNULL( (select CREATION_DATE  from  pur_bidding_supplier_line pbsl where  pbsh.HEAD_ID = pbsl.HEAD_ID  order by CREATION_DATE desc LIMIT 1 ) ,  pbsh.CREATION_DATE) as CREATION_DATE,
        IFNULL((select LINE_ID  from  pur_bidding_supplier_line pbsl where  pbsh.HEAD_ID = pbsl.HEAD_ID  order by CREATION_DATE desc LIMIT 1 ) ,0) as LINE_ID,
        CONVERT(IFNULL((select QUOTED_PRICE  from  pur_bidding_supplier_line pbsl where  pbsh.HEAD_ID = pbsl.HEAD_ID  order by CREATION_DATE desc LIMIT 1 ),99999999999999999999999),decimal(20,2)) as QUOTED_PRICE,
            pbsh.SUPPLIER_ID,
            ps.SUPPLIER_NAME,
            pe.PRO_ID ,

            ( select glook from pur_program  p  where p.pro_id=pe.PRO_ID) as GLOOK,
            ( select AGENTLOOK from  pur_program   p where p.pro_id=pe.PRO_ID) as AGENTLOOK
        FROM

            pur_bidding_supplier_head pbsh,
            pur_evaluation pe,
            pur_supplier ps
        WHERE
           pe.EVALUATION_ID = pbsh.EVALUATION_ID
          AND ps.SUPPLIER_ID = pbsh.SUPPLIER_ID
          AND pe.PRO_ID = #{0}
        ORDER BY
            pbsh.CREATION_DATE DESC

最后通过上面红色部分的convert函数来实现转成保留两位小数。
转换前的数据
2021-07-06 10:43:00  26506  88889.0  6302  李盛超测试
2021-07-06 10:47:06  26518  1500.1  6306  黄彤测试账号
2021-07-06 10:43:00  26508  6666.1  6304  顾志坚测试账号

转换后的数据
2021-07-06 10:43:00  26506  88889.02  6302  李盛超测试
2021-07-06 10:47:06  26518  1500.08  6306  黄彤测试账号
2021-07-06 10:43:00  26508  6666.05  6304  顾志坚测试账号

7月2

sql 多表关联更新方法

21:11数据库  From: 本站原创
#表结构:
1、表一:Test1
Id  name  age
1      
2      

2、表二:Test2
Id  name  age
1  小明  10
2  小红  8


#实现将表Test2的name和age字段数据更新到表Test1中,按照id相等的条件

1、SQLServer多表更新方法:
语法:

UPDATE { table_name WITH ( < table_hint_limited > [ ...n ] ) &#124; view_name &#124; rowset_function_limited }
SET { column_name = { expression &#124; DEFAULT &#124; NULL } &#124; @variable = expression &#124; @variable = column = expression } [ ,...n ]
{ { [ FROM { < table_source > } [ ,...n ] ] [ WHERE < search_condition > ] } &#124; [ WHERE CURRENT OF { { [ GLOBAL ] cursor_name } &#124; cursor_variable_name } ] } [ OPTION ( < query_hint > [ ,...n ] ) ]
例子:

update test1
set test1.name=test2.name,test1.age=test2.age
from test1
inner join test2
on test1.id=test2.id

2、Oracle 多表更新方法:
语法:

UPDATE updatedtable
SET (col_name1[,col_name2...])= (SELECT col_name1,[,col_name2...]
FROM srctable [WHERE where_definition])
例子:

update test1
set (test1.name,test1.age)=
(select test2.name,test2.age from test2 where test2.id=test1.id)

3、MySql多表更新方法:
语法:

UPDATE table_references
SET col_name1=expr1 [, col_name2=expr2 ...] [WHERE where_definition]
例子:

update test1,test2
set test1.name=test2.name,test1.age=test2.age
where test1.id=test2.id

4、通用方法:(*^__^*)
update test1
set name=(select name from test2 where test2.id=test1.id),
age=(select age from test2 where test2.id=test1.id)
分页: 1/4 第一页 1 2 3 4 下页 最后页 [ 显示模式: 摘要 | 列表 ]