利用 Python 脚本进行 MySQL 数据库（表）传输
Usage Example： 1234567Copy 整个 database:python mysql_transfer.py --src-host=127.0.0.1 --src-user=root --src-password=123 --src-db=源db \ --tgt-host=127.0.0.1 --tgt-user=root --tgt-password=456 --tgt-db=目标dbCopy 指定 tables:python mysql_transfer.py --src-host=127.0.0.1 --src-user=root --src-password=123 --src-db=源db \ --tgt-host=127.0.0.1 --tgt-user=root --tgt-password=456 --tgt-db=目标db --tables source_table1:target_table1 source_table2:target_table2 Python Script(mysql_transfer.py)： 12345678...
关于 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 id=&...
SQL 语句优化的一些方法
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 ...
记录 binlog 的使用
配置文件 先看配置文件 启用了才有这样的记录默认是没有的 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 ...
MySQL 数据库设计规范
数据库设计基本规范数据库 采用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 大小写敏感 表/列/索引命名 全部采用英文单词小写，单词间下划线分割，禁用拼音 表明中包含的单词采用单数，禁用复数 表名以**业务名称_**开头， 列名以表名**业务名称_xxx的xxx**开头，(除了逻辑删除列、创建时间、更新时间和关联其他表的列之外所有属于本表的基本字段...
MySQL 用户权限总结
转自: https://blog.csdn.net/yeahPeng11/article/details/121584343 一、MySQL用户权限 MySQL版本5.7 背景 在开发过程中数据库安装在云服务器，本地连接阿里云服务器中的MySQL就不能直接root用户连接，而每次数据库操作都要使用新建的用户与用户进行交互操作。 在使用非root用户的时，执行本地的sql文件，就需要一些权限，比如 SELECT,INSERT,UPDATE,DELETE,CREATE 等等权限 添加MySQL用户并设置权限的好处：新的SQL用户不允许访问访问属于其他SQL用户的库或表，甚至不能使用SELECT语句。新的SQL用户必须显式的被授予权限，才能执行对应的操作。 二、用户权限介绍1.权限级别 全局：可以管理整个MySQL 数据库：可以管理指定的数据库 数据表：可以管理指定数据库的指定表 字段：可以管理指定数据库的指定表的指定字段 权限存储在mysql库的user,db,tables_priv,columns_priv,procs_priv这几个系统表中，待MySQL实例启动后就加载到内存...
MySQL 集群部署
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 /mydata/mysql/master/...
MySQL 时间字段选择
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. 既要保证兼容,又要确保可拓展(其实很简单,就是分片键传参粒度高些) 分表及数据迁移(存储过程) 12345678910111213141516171819202122232425262728293031323334353...
MySQL EXPLAIN 之 UsingTemporary 和 UsingFilesort 解决案例
首先查看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 filesort这个令人讨厌的头颅了 注意：必须依照顺序，在创建组合索引时，where条件的字段在orderBy的字段之前，如果orderBy是多字段，则必须依照顺序创建 详情可参考链接：https://blog.csdn.net/dingxingmei...
公告