事务用于保证数据的一致性,它由一组相关的dml语句组成,该组的dml语句要么全部成功，要么全部失败。如:转账就要用事务来处理,用以保证数据的一致性。
最近说来惭愧，有开始说mysql 5.6 的问题了，是在是无奈有一个项目古老且XX，大批的在用MySQL 5.6 这个版本的数据库，之前并未进行管理，但基于Enterprise 的数据库都管理的还可以，所以这个项目也就到了手里，然后我们提出从5,6升级数据库版本的问题，并提出升级后的各种利好，但在升级过程中，我们遇到了升级后，又降级回去的问题，这里和各位说说为什么，以及我们疏忽了什么。
MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你即需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务.
作为一名 DBA 碰到过升级出问题需要回退么？碰到过回退还解决不了问题么？我有幸遇到了一次凶险的升级“血案”。
事务 为保证业务的完整性，当一条语句出现错误，则此步骤全部回退 原子性(Atomicity)：事务中的全部操作在数据库中是不可分割的，要么全部完成，要么均不执行 一致性(Consistency)：几个并行执行的事务，其执行结果必须与按某一顺序串行执行的结果相一致 隔离性(Isolation)：事务的执行不受其他事务的干扰，事务执行的中间结果对其他事务必须是透明的 持久性(Durability)：对于任意已提交事务，系统必须保证该事务对数据库的改变不被丢失，即使数据库出现故障 提交 默认隔离级别可重复读
团队合作的时候为了避免代码冲突，以及方便记录修改历史和回退我们有版本控制比如说 git svn
首先来说MySQL升级后性能下降，在我从事MySQL DBA这10多年中也遇到几次，而且排查难度比较大。这里给大家提供一个MySQL升级管管理方案供大家参考。内容较长，建议收藏后以方便查阅。
作为万里数据库的战略合作伙伴，某运营商一直密切关注着国产数据库的发展。其系统中一套基于MySQL8.0.11版本的核心报表平台，近期由于存在安全扫描的漏洞，需要尽快将其升级到MySQL8.0.25及以上版本。
Win mysql安装：Windows下安装MySQL详细教程 - m1racle - 博客园 (cnblogs.com)
这个其实用脚趾头想想也知道它的重要性，举个简单的例子： 一个用户提交了一个订单，那么这条数据包含了两个信息，用户信息 和购买的 商品信息，我需要把他们分别存到 用户表 和 商品表，如果不采用事务，可能会出现，商品信息插入成功，而用户信息没有，这时候就会出现无主商品了，用户付了钱，却得不到商品，这就尴尬了，而如果采用事务，就可以保证，用户信息 和 商品信息 都必须插入成功，该次事务才算成功，那就不会出现这种问题了
可以看到表定义中出现了AUTO_INCREMENT=2，表示下一次插入数据时如果需要自动生成自增值，那么id便是2。
goose是一个用go语言编写的数据库版本管理的命令行工具。其github地址如下：https://github.com/pressly/goose
聚集函数（aggregate function） 运行在行组上，计算和返回单个值的函数
本文将详细剖析Canal在初次启动时如何定位同步位点，行为思路先源码，再辅以流程图进行说明，并在总结部分使用思维导图进行总结，试图引发各位的讨论。
Undo日志：undo log是mysql中两种比较重要的事务日志，另外一种是redo log，undo log顾名思义，是一种用于撤销回退的日志，用于事务没提交之前，会先记录存放到 Undo 日志文件里，当事务回滚时或者数据库崩溃时，可以利用 Undo 日志回退事务
然后插入数据，最后看到，表会自动生成一个AUTO_INCREMENT的值，ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=latin1 ,表示下一次插入数据时，如果需要自动生成自增值，会生成 id=11。
结合实例分析了自增值保存在哪里，自增值的修改策略，以及自增值不连续的四个场景，希望对各位小伙伴们有所帮助~
最近在推一些业务迈入MySQL 8.0,对很多同学来说，好像差别不大，对于我们来说却是一个质的变化，光看版本就能够感受出来，5.7-> 8.0，所幸我们3年前就迈入了5.7版本，多多少少也把5.7的特性都经历差不多了。
在开发过程中，需要修改数据库模型，而且还要在修改之后更新数据库。最直接的方式就是删除旧表，但这样会丢失数据。
如果回滚到上面设置的保存点s1,那么account表中的数据自然就没有了。这就是回滚事务。
升级之前必须备份数据 必须备份数据 必须备份数据 ,一旦升级mysql8.0无法回退 不备份就等死
undo log是mysql中比较重要的事务日志之一，顾名思义，undo log是一种用于撤销回退的日志，在事务没提交之前，MySQL会先记录更新前的数据到 undo log日志文件里面，当事务回滚时或者数据库崩溃时，可以利用 undo log来进行回退。
日常运维中, 难免遇到切换的场景, 但mysql的主从是逻辑复制, 没得真正的所谓MASTER,SLAVE. 主从复制无非就是几个特殊的进程而已. 感兴趣的可以看下之前写的mysql主从连接相关文章
对于商业数据库而言，数据库升级是一个优先级很高的事情，有版本升级路线图，有相应的补丁，而且对于方案还有一系列的演练，显然是一场硬仗。而在MySQL方向上，升级这件事情就被淡化了许多，好像只能证明它的存在而已，当然正是由于这种不重视，也让我今天走了不少弯路。
git config 操作git管理中的配置信息 git init 初始化git本地仓库 git add 添加新文件到git管理 git commit 提交暂存区文件到本地仓库 git push 将本地仓库文件推送远程仓库 git pull 将远程仓库文件拉取到本地并合并到当前分支 git fetch 拉取远程仓库中指定分支文件 git branch 查看/添加/删除分支 git checkout切换分支 git merge合并分支 git tag 添加/查看/编辑标签 git stash 暂存文件 git log / git reflog 查看提交历史记录 git reset 版本回退
本文由腾讯云+社区自动同步，原文地址 http://blogtest.stackoverflow.club/119/
AUTO_INCREMENT=2，表示下一次插入数据时，若需要自动生成自增值，会生成id=2。
通常来说，不管使用什么数据库，表里都有一个名为 id 的主键，既然是主键，那么必然要满足唯一性，对于 MySQL 用户来说，它多半是一个 auto_increment 自增字段，也有一些别的用户喜欢使用 UUID 做主键，不过对 MySQL（特别是 InnoDB）来说，UUID 通常不是一个好选择，因为聚簇索引要求物理数据按照主键排序，而 UUID 本身是无序的，所以会带来很多不必要的 IO 消耗。于是乎我们得到一个结论：ID 最好是顺序的唯一值。
作者简介 Openstack迭代很快，半年一次的更新往往会引入新的特性，及原有功能的完善。版本升级成为了一个不可避免的问题。由于openstack升级的复杂性许多公司和团队采用直接迁移至新
触发器是一种特殊的存储过程，它在插入，删除或改动特定表中的数据时触发运行，它比数据库本身标准的功能有更精细和更复杂的数据控制能力。
Netfilix创建了一个名为Hystrix的库，实现了熔断器模式。在微服务架构中，它通常有多个服务调用层。
在最近的一个大型项目中，用户提到由我们云提供商进行Oracle数据库的备份、迁移集成工作，是选择用DG、还是RMAN？我们今天来分析一下。
看到percona发了篇Do Not Upgrade to Any Version of MySQL After 8.0.37. 说是mysql新版本有BUG.
作为最核心的秒杀功能，主要在于能够保证用户抢购商品时的流畅性，为了能够让用户更快地获取秒杀商品，前台用户的秒杀商品都是通过Redis中获取，并且使用Spring Boot定时任务，每隔五秒将Redis的商品数据和MySQL数据库中的数据进行交互，保证数据的有效性。
大多数 SQL 实现支持以下类型的函数。 ❑ 用于处理文本字符串（如删除或填充值，转换值为大写或小写）的文本函数。❑ 用于在数值数据上进行算术操作（如返回绝对值，进行代数运算）的数值函数。 ❑ 用于处理日期和时间值并从这些值中提取特定成分（如返回两个日期之差，检查日期有效性）的日期和时间函数。 ❑ 用于生成美观好懂的输出内容的格式化函数（如用语言形式表达出日期，用货币符号和千分位表示金额）。 ❑ 返回 DBMS 正使用的特殊信息（如返回用户登录信息）的系统函数
最近在改进一套环境的延迟问题，做了业务层的优化之后，问题得到了基本的解决，但是离我预想中的结果还是有距离，毕竟高峰期的延迟还是有20多秒，有些尴尬。
爱可生开源社区的 DTLE ，自开源起一直定位于一款针对 MySQL 使用特点、支持多种使用场景的数据传输组件，希望能够解决当前 MySQL 应用中保障数据传输质量、能够适配复杂场景、提供多样功能的问题。
1. 官网下载并解压 我下载的是mysql-8.0.11-winx64 下载地址:https://dev.mysql.com/downloads/file/?id=476233 2. 设置系统环境变量
在客户容灾方案建设过程中，客户侧迁移数据库实例到云上MySQL是一个非常普遍的需求。目前最常用的迁移通用方案是较成熟的方案，一般迁移过程都可以采用此方案；但通用方案存在一个不方便之处：迁移过程中的业务切换是一个难点，调整业务数据库连接配置，将读写数据源切换为CDB实例的IP。调整业务数据库连接配置这一步很可能存储遗漏的情况，前端业务在长时间的发展过程中，存在多个连接数据库的源，一次性调整访问源到目标是比较困难的。
在版本迭代开发过程中，相信很多人都会有过错误提交的时候（至少良许有过几次这样的体验）。这种情况下，菜鸟程序员可能就会虎驱一震，紧张得不知所措。而资深程序员就会微微一笑，摸一摸锃亮的脑门，然后默默的进行版本回退。
为了解决上述问题，数据库通过锁机制 解决并发访问的问题。根据锁定对象不同：分为行级锁和表级锁；根据并发事务锁定的关系上看：分为共享锁定和独占锁定，共享锁定会防止独占锁定但允许其他的共享锁定。而独占锁定既防止共享锁定也防止其他独占锁定。为了更改数据，数据库必须在进行更改的行上施加行独占锁定，insert、update、delete 和 select for update 语句都会隐式采用必要的行锁定。
中信银行的某个大佬在一个会议中提及中信银行将成为中国第一个在技术上支持生僻字的商业银行。由于历史原因，我们的MySQL部署规范提供的字符集为utf8字符集，需要将数据库的字符集集体转换为utf8mb4。
随着互联网快速发展，以及微服务架构的流行，服务器的压力越来越大。上一篇介绍的 Docker Compose 项目，可以将多个容器捏合在一起，实现容器间的通信，比如 Web 项目对 DB、Cache 的依赖，以及微服务之间的通信等。但这还是远远不够的，Docker Compose 仅仅局限在一个 Docker 主机上，服务器的压力仍然没有得到解决，怎么办呢？集群呗！Docker Swarm 可以将多个 Docker 主机 集群成一个大型的虚拟 Docker 主机，然后在上面部署服务，当服务器压力上来时，不断的往 Swarm 集群中添加 Docker 主机就行了！更重要的，不必像传统发布那样，在每台服务器上都运行一遍分布式项目，大大节约了流程和工作量。
迁移部分数据, 目标端还有数据, 基本上就确定使用mysqldump工具来做了
触发器（trigger）是数据库中的一个很重要的、很实用的基于事件的处理器，在处理一些业务需求的时候，使用触发器会很方便。似乎在《高性能MySQL》中，对触发器作了一定的描述，也提到使用中的一些优势和局限性，但感觉还是不能完全理解触发器的全部功能和实现。于是自己在网上看了一些文章，结合官网（https://dev.mysql.com/doc/refman/8.0/en/trigger-syntax.html）中的案例，写下这篇总结。
在 第4篇 文章中，我们提到过自增主键，由于自增主键可以让主键索引尽量地保持递增顺序插入，避免了页分裂，因此索引更紧凑。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
