mysql

关于MySQL的死锁 MySQL的死锁指的是两个事务互相等待的场景，这种循环等待理论上不会有尽头。 比如事务A持有行1的锁，事务B持有行2的锁，然后事务A试图获取行2的锁，事务B试图获取行1的锁，这样事务A要等待事务B释放行2的锁，事务B要等待事务A释放行1的锁，两个事务互相等待，谁也提交不了。 这种情况下MySQL会选择中断并回滚其中一个事务，使得另一个事务可以提交。MySQL会记录死锁的日志。 制造一个死锁的场景新建一个表，添加两条数据： 创建两个事务，事务执行的sql分别是： 事务A： 1234set autocommit=0;update medicine_control set current_count=1 where id='1';update medicine_control set current_count=1 where id='2';COMMIT; 事务B： 1234set autocommit=0;update medicine_control set current_count=2 where...

sql语句优化的一些方法避免全表扫描对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 避免在 where 子句中使用!=或<>操作符应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 避免在 where 子句中对字段进行 null 值判断应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： 12345select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=0 避免在 where 子句中使用 or 来连接条件应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： 123456789select id from t where num=10 or num=20可以这样查询：select id from...

配置文件 先看配置文件 启用了才有这样的记录默认是没有的 linux系统中的 /etc/my.cnf my.cnf内容：log-bin = mysqlbin # 默认配置，mysqlbin 为binlog文件名称 binlog文件一般放在/var/lib/mysql比如上面的设置重启数据库会生成mysqlbin.000001文件，并放在/var/lib/mysql下 自定义文件存放位置修改配置文件，vi /etc/my.cnf，找到log-bin的部分配置自动清理在my.cnf文件中，这个文件路径不知道的话执行mysql --help | grep 'Default options' -A 1，就会列出文件的路径来 然后重启service mysql restart，去新建的目录下看看，已经有最新的日志了 下面列几个常用的命令查看bin_log相关信息show variables like '%log_bin%'; 查看日志开启状态show variables like...

数据库设计基本规范数据库 采用InnoDB引擎，禁用其他类型引擎 采用utf8mb4字符集 只允许访问所属数据库，禁止跨库访问 禁止临时任务表长期存在于数据库中 创建数据库/表的时候，还要对排序规则进行审查： 需要区分特殊字符：默认的general_ci 更快，但是unicode_ci 更准确，utf8mb4_general_ci中S=ß，而utf8mb4_unicode_ci中ss=ß ，这种情况unicode_ci能准确判断（参考：http://mysql.rjweb.org/utf8mb4_collations.html） 大小写敏感：默认的general_ci大小写不敏感，utf8mb4_unicode_ci大小写不敏感，但utf8mb4_bin...

转自: https://blog.csdn.net/yeahPeng11/article/details/121584343 一、MySQL用户权限 MySQL版本5.7 背景 在开发过程中数据库安装在云服务器，本地连接阿里云服务器中的MySQL就不能直接root用户连接，而每次数据库操作都要使用新建的用户与用户进行交互操作。 在使用非root用户的时，执行本地的sql文件，就需要一些权限，比如 SELECT,INSERT,UPDATE,DELETE,CREATE...

Mysql常见集群方式 Mysql-MMM（mysql主主复制管理器） MHA（Mysql高可用方面是一个相对成熟的方案） InnoDB Cluster（支持自动Failover，强一致性，读写分离，读库高可用，读请求负载均衡，推荐方案） 主从同步创建Master实例并启动123456docker run -p 3307:3306 --name mysql-master \-v /mydata/mysql/master/log:/var/log/mysql \-v /mydata/mysql/master/data:/var/lib/mysql \-v /mydata/mysql/master/conf:/etc/mysql \-e MYSQL_ROOT_PASSWORD=root \-d mysql:5.7 参数说明： 123-p 3307:3306:将容器的3306映射到主机的3307端口-v 挂载-e 初始化root用户密码 修改master基本配置123456789101112131415161718vim...

MySQL 5.6 版本开始 DATETIME 和 TIMESTAMP 精度支持到毫秒 DATETIME 占用 8 个字节，TIMESTAMP 占用 4 个字节，DATETIME(6) 依然占用 8 个字节，TIMESTAMP(6) 占用 7 个字节 TIMESTAMP 日期存储的上限为 2038-01-19 03:14:07，业务用 TIMESTAMP 存在风险 使用 TIMESTAMP 必须显式地设置时区，不要使用默认系统时区，否则存在性能问题，推荐在配置文件中设置参数 time_zone = '+08:00' 推荐日期类型使用 DATETIME，而不是 TIMESTAMP 和 INT 类型 表结构设计时，每个核心业务表，推荐设计一个 last_modify_date 的字段，用以记录每条记录的最后修改时间

最近一个项目模块的数据库要进行结构调整优化,所以这里记录一下 首先我们是做汽车后市场业务的产品, 所有的业务和车型的sku数据息息相关,所以关于车型服务模块的压力在同比当中是比较大的。而目前我们的问题是qps并不高,但是数据库的cpu却经常7/8十 为什么会这样? 主要是该模型库的数据量庞大,数据表结构厚,导致在qps并不高的时候cpu消耗也比较高.所以大qps,小cpu消耗是我们解决问题的方向 前景有了,接下来就是解决问题的方案 数据库调整,怎么调整?从表思考两个方向 长度-数据量 厚度-表结构 上游调用需要频率 当然具体探讨流程就不叙述了(这里涉及到业务的东西很多),最终领导敲板车型库其中两个数据量庞大,调用频率高的表按分片键水平分表 这里记一下整体调整的过程 接口服务调整 121. 所有有关这俩表的crud都必须带上分片键2....

MySQL优化之Using temporary（临时表）、Using filesort（文件排序）首先查看explain执行计划，让主要查询语句使用索引，索引type级别最好达到ref | ref_eq级别 其次将extra一栏的Using temporary（临时表）、Using filesort（文件排序）拖出去砍了 第一条语句 123explain select * from tb_wm_shop where is_delete != 1 and is_authentication = 1 ORDER BY create_time DESC 大家应该知道使用order by的 字段要使用索引，这条语句中create_time已经创建了索引，但是计划中并没有使用该索引，导致出现了Using filesort文件排序，使其查询变慢 解决方法如下： 从where条件开始，依照顺序创建一个组合索引，就可以砍掉Using...

首先项目里有一条类似这样的sql123456789101112131415161718select tr.xxx tr.cm_ids, group_concat(te.xxx) a, group_concat(te.xxx) b, group_concat(te.xxx) c, group_concat(te.xxx) d,from (select tr.1, tr.2, tr.3, group_concat(cm_id) cm_ids from xxx tr where tr.xxx = '123' group by tr.1,tr.2,tr.3) tr left join xxx tc on tr.xxx = tc.xxx left join xxx te on tr.xxx = te.xxxgroup by...