一个真实的业务系统中，往往存在大量的类似字典表的数据表，它们与业务表之间可能有关系，这种关系，可以理解为“标签”，而不应理解为通常的 “主从关系”，这些表基本上很少变动，可以根据主键 ID进行缓存，下面这张图说明了一个典型的“标签关系”图： image.png 1、全局表描述 在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，考虑到字典表具有以下几个特性： • 变动不频繁 • 数据量总体变化不大 • 数据规模不大，很少有超过
全局读锁通常是由flush table with read lock;这类语句添加的。在各种备份工具为了得到一致性备份，已经在具备主从复制架构的环境中做主备切换时常常使用这类语句。另外还有一种情况，可是最难排查的一种情况，就是线上系统权限约束不规范，各种人员使用的数据库账号都有RELOAD权限，都可以对数据库加全局读锁。
在MySQL数据库的存储过程和函数中，可以使用变量来存储查询或计算的中间结果数据，或者输出最终的结果数据。
局部索引等价于我们通常说的本地索引，与主表的数据结构保持一对一的关系。局部索引没有单独分区的概念，一般来讲，主表的分区方式决定局部索引的分区方式，也就是说假设主表有10个分区，那么对于每个分区来讲，都有一个对应的局部索引。
在前面一些文章中，经常能看到介绍某某参数的作用，可能有些小伙伴仍搞不清楚 MySQL 参数是啥。本篇文章我们来聊聊 MySQL 参数，学习下如何管理维护 MySQL 参数。
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wzy0623/article/details/53908632
使用MYSQL有一段时间了，由于公司使用SQLSERVER和MYSQL，而且服务器数量和数据库数量都比较多
2.替换 spring.xml 配置文件中的 sqlSessionFactory
聊一个实际问题：淘宝的数据库，主键是如何设计的？ 某些错的离谱的答案还在网上年复一年的流传着，甚至还成为了所谓的MySQL军规。其中，一个最明显 的错误就是关于MySQL的主键设计。
Mysql数据库在处理并发中下了很多功夫，锁是为了更好的保护数据的正确和可靠，Mvcc是维持一个数据的多个版本，使得读写操作没有冲突的解决并发的数据库方案。
今天是《MySQL核心知识》专栏的第4章，今天跟大家一起聊聊MySQL的简单语法。好了，开始今天的正题。
1.导入mybatis-plus包 <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus</artifactId> <version>2.1-gamma</version> </dependency> <dependency> <groupId>org.apache.velocity</groupId> <artifactId>velocity</artifactId> <version>1.7</
设置有两种，如下： (1) 设置balance="1"与writeType="0"
MyCAT的目标是：低成本的将现有的单机数据库和应用平滑迁移到“云”端，解决数据存储和业务规模迅速增长情况下的数据瓶颈问题。
我们现在默认使用的都是root用户，超级管理员，拥有全部的权限。但是，一个公司里面的数据库服务器上面可能同时运行着很多个项目的数据库。所以，我们应该可以根据不同的项目建立不同的用户，分配不同的权限来管理和维护数据库。
在上一期《优化器成本记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql 系统库中的优化器成本记录表，本期我们将为大家带来系列第六篇《时区信息记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！
世间万物，都有自己唯一的标识，比如人，每个人都有自己的指纹（白夜追凶给我科普的，同卵双胞胎DNA一样，但指纹不一样）。又如中国人，每个中国人有自己的身份证。对于计算机，很多时候，也需要为每一份数据生成唯一的标识。在这里，数据的概念是非常宽泛的，比如数据量记录、文件、消息，而唯一的标识我们称之为id。 自增ID 使用过mysql的同学应该都知道，经常用自增id（auto increment）作为主键，这是一个为long的整数类型，每插入一条记录，该值就会增加1，这样每条记录都有了唯一的id。自增id应该是使
Join 绝对是关系型数据库中最常用一个特性，然而在分布式环境中,跨分片的 join 确是最复杂的，最难解决一个问题。
哈喽，好久没更新啦。因为最近在面试。用了两周时间准备，在 3 天之内拿了 5 个 offer，最后选择了广州某互联网行业独角兽 offer，昨天刚入职。这几天刚好整理下在面试中被问到有意思的问题，也借此机会跟大家分享下。
事务是MySQL的Innodb存储引擎比较大的亮点，大家对事务的隔离级别肯定都不陌生，那么如何查看当前事务的隔离级别呢？这个方法可能大家也知道，不就是查看当前的transaction_isolation变量么？下面我们分三个部分给说说这个修改隔离级别的操作：
某些错的离谱的答案还在网上年复一年的流传着，甚至还成为了所谓的MySQL军规。其中，一个最明显的错误就是关于MySQL的主键设计。
Mycat是一个开源的分布式数据库系统，是一个实现了MySQL协议的的Server，前端用户可以把它看作是一个数据库代理，用MySQL客户端工具和命令行访问，而其后端可以用MySQL原生（Native）协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信，其核心功能是分表分库，即将一个大表水平分割为N个小表，存储在后端MySQL服务器里或者其他数据库里；
$ mysql -uroot -p mysql>set password=password('your_passord');
MySQL CDC连接器允许从MySQL数据库读取快照数据和增量数据。本文档根据官网翻译了如何设置MySQL CDC连接器以对MySQL数据库运行SQL查询。
大家好，最近粉丝问我这样的一个面试题。MySQL的自增 ID 用完了，怎么办？以下是这个面试题的解决方案。
GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID，它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。本文主要描述了快速配置一个基于GTID的主从复制架构，供大家参考。 一、GTID的概念 1、全局事务标识：global transaction identifiers。 2、GTID是一个事务一一对应，并且全局唯一
unique、 primary key、not null、default相对简单，本篇文章不做记录。
最近的工作主要是微服务框架的设计与开发，期间要解决多个微服务的分布式事务问题，由于要解决的主要场景是用spring boot写的java项目，最终选择了业界成熟的servicecomb-saga方案，这里稍微记录下以备忘。
如果你用过或了解过MySQL，那你一定知道自增主键了。每个自增id都是定义了初始值，然后按照指定步长增长（默认步长是1）。虽然，自然数是没有上限的，但是我们在设计表结构的时候，通常都会指定字段长度，那么，这时候id就有上限了。既然有上限，就总有被用完的时候，如果id用完了，怎么办呢？今天就一起来学习下吧。
对一个固定的技术组件的分析优化思路，即组件不是我们开发的，但又要分析优化它，怎么办？
GTID即全局事务ID (global transaction identifier), 其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。GTID最初由google实现，官方MySQL在5.6才加入该功能。mysql主从结构在一主一从情况下对于GTID来说就没有优势了，而对于2台主以上的结构优势异常明显，可以在数据不丢失的情况下切换新主。使用GTID需要注意: 在构建主从复制之前，在一台将成为主的实例上进行一些操作（如数据清理等），通过GTID复制，这些在主从成立之前的操作也会被复制到从服务器上，引起复制失败。也就是说通过GTID复制都是从最先开始的事务日志开始，即使这些操作在复制之前执行。比如在server1上执行一些drop、delete的清理操作，接着在server2上执行change的操作，会使得server2也进行server1的清理操作。
在 MySQL 数据库的存储过程和函数中，可以使用变量来存储查询或计算的中间结果数据，或者输出最终的结果数据。
如果你用过或了解过MySQL，那你一定知道自增主键了。每个自增id都是定义了初始值，然后按照指定步长增长（默认步长是1）。虽然，自然数是没有上限的，但是我们在设计表结构的时候，通常都会指定字段长度，那么，这时候id就有上限了。
最近，又遇到了慢 SQL，简单的看了下，又是因为 MySQL 本身优化器还有查询计划估计不准的问题。SQL 如下：
在MySQL最新的官方文档中，关于XA Transactions的介绍有这么一段描述：
我们都是知道，数据库中锁的设计是解决多用户同时访问共享资源时的并发问题。在访问共享资源时，锁定义了用户访问的规则。根据加锁的范围，MySQL 中的锁可大致分成全局锁，表级锁和行锁三类。在本篇文章中，会依次介绍三种类型的锁。在阅读本篇文章后，应该掌握如下的内容：
在MySQL数据库管理与操作中，Binlog（二进制日志）的角色不容忽视。它记录了数据库的所有更改操作，对于数据复制、恢复和分析具有重要意义。在这个过程中，理解Binlog日志的位置定位是至关重要的。本文将为大家揭示Binlog日志位置的字节单位定位以及其他相关定位概念，助力大家更准确地操作和分析Binlog日志。
config.ini文件中的[mysqld]和[api]部分定义了用于访问集群数据的 MySQL 服务器（SQL 节点）和其他应用程序（API 节点）的行为。所示的参数都不是必需的。如果未提供计算机或主机名，则任何主机都可以使用此 SQL 或 API 节点。
经过前面6个篇幅的学习，相信大家对什么是performance_schema，已经初步形成了一个整体认识，但我想很多同行看完之前的文章之后可能还是一脸懵逼，今天就为大家带来performance_schema系列的最后一个篇章(全系共7个篇章)，在这一期里，我们将为大家列举数十个performance_schema应用示例。下面，请跟随我们一起开始performance_schema系统的学习之旅吧。
如果你对Flink CDC 还没有什么概念，可以参考这里：Flink CDC 原理及生产实践。
MySQL提供了不同等级的锁，按限制能力的划分，分为全局锁、表锁、行锁。本文会描述不同锁的应用场景与实现原理。
昨天项目中遇到部分服务一直是pending状态，排查了代码和重启了服务都没能解决问题，于是从数据库开始排查。
general_log指的是日志保存状态，一共有两个值（ON/OFF）ON代表开启 OFF代表关闭。
每周六晚上我们几个小伙伴都会组织一个技术研讨会，就技术群里大家提出的几个有意思的问题做重点的讨论。主持人采用轮流主持的模式，本周由我负责组织和分享，这篇文章就是我们当时研习小组讨论的纪要。想要加入的小伙伴可以看文章最末尾的广告时间。
来源 | https://mp.weixin.qq.com/s/Yqo5PaTtQcQTn4p8BE6SGg
资深数据库专家，专研 MySQL 十余年。擅长 MySQL、PostgreSQL、MongoDB 等开源数据库相关的备份恢复、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相关技术支持、MySQL 相关课程培训等工作。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
