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/...
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 ...
关于 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=&...
记一次数据库结构优化经验——水平分表
最近一个项目模块的数据库要进行结构调整优化,所以这里记录一下 首先我们是做汽车后市场业务的产品, 所有的业务和车型的sku数据息息相关,所以关于车型服务模块的压力在同比当中是比较大的。而目前我们的问题是qps并不高,但是数据库的cpu却经常7/8十 为什么会这样? 主要是该模型库的数据量庞大,数据表结构厚,导致在qps并不高的时候cpu消耗也比较高.所以大qps,小cpu消耗是我们解决问题的方向 前景有了,接下来就是解决问题的方案 数据库调整,怎么调整?从表思考两个方向 长度-数据量 厚度-表结构 上游调用需要频率 当然具体探讨流程就不叙述了(这里涉及到业务的东西很多),最终领导敲板车型库其中两个数据量庞大,调用频率高的表按分片键水平分表 这里记一下整体调整的过程 接口服务调整 121. 所有有关这俩表的crud都必须带上分片键2. 既要保证兼容,又要确保可拓展(其实很简单,就是分片键传参粒度高些) 分表及数据迁移(存储过程) 12345678910111213141516171819202122232425262728293031323334353...
记录 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 时间字段选择
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 的字段，用以记录每条记录的最后修改时间
记录工作中遇到慢 SQL 的情况和解决办法（长期）
left join查询加where条件, 用到了索引, 但是仍然几乎全表扫, explain-type为index, 用到的索引为联合索引,但where条件字段不符合最左原则(例如索引是key index (a,b,c). 可以支持a | a,b| a,b,c 3种组合进行查找，但不支持 b,c进行查找), 所以最后解决办法是建立了条件字段的索引 单表同时查询多个字段和聚合函数的时候, 建立一个聚合索引(包含聚合函数字段)可能比单个字段索引效率要高(单个字段会回表)
记录因 group_concat 函数长度限制引起的问题
首先项目里有一条类似这样的sql 123456789101112131415161718select 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 tr.1,tr.2...
Nginx 反向代理中 proxy_set_header 参数说明
转自: https://www.cnblogs.com/kevingrace/p/8269955.html Nginx proxy_set_header：**即允许重新定义或添加字段传递给代理服务器的请求头。该值可以包含文本、变量和它们的组合。**在没有定义proxy_set_header时会继承之前定义的值。默认情况下，只有两个字段被重定义： 12proxy_set_header Host $proxy_host;proxy_set_header Connection close; 如果启用缓存，来自之前请求的头字段“If-Modified-Since”, “If-Unmodified-Since”, “If-None-Match”, “If-Match”, “Range”, 和 “If-Range” 将不会被代理服务器传递。一个不会变化的“Host”头请求字段可通过如下方式被传递： 1proxy_set_header Host $http_host; 然后，当字段不在请求头中就无法传递了，在这种情况下，可通过设置Host变量，将需传递值赋给Host变量 1proxy...
公告