23.提升回滚大表操作的方法
DBA有时会遇到操作一张大表,发现操作时间过长或者影响在线业务了,想要回退大表操作。对于提升大事务回滚效率,官方提供了两种方法:
一是增加innodb_buffer_pool_size参数大小,二是合理利用innodb_force_recovery=3参数,跳过事务回滚过程。第一种方式比较温和,innodb_buffer_pool_size参数是可以动态调整的,可行性也较高。第二种方式相较之下较暴力,但效果较好。
第二种方法操作流程如下:
kill -9 MySQL 进程;备份MySQL数据及日志目录;为MySQL Server设置innodb_force_recovery=3参数;然后启动MySQL进程;正常关闭MySQL Server进程;去掉innodb_force_recovery=3参数启动MySQL进程。完成恢复过程。(innodb_force_recovery这个参数一般都用于“严重故障排除场景”,生产环境慎用,若用于生产环境需首先明确innodb_force_recovery设置对现有生产数据可能的影响情况)。
在完成最后启动操作之后,错误日志种会记录一条“【note】Inn哦DB:Rollback of non-prepared transactions completed”信息。此方式无需等待事务回滚操作,完成上述操作步骤的时间即位环境恢复的时间。
两种方式各有自己的优点,第一种方式对线上业务系统影响较小,不会中断在线业务。第二种方式效果更显著,会短暂影响业务连续,回滚所有没有提交的事务。
24 关于log_error_verbosity参数设置
参数取值 | 影响范围 | 是否默认 |
1 | errors only. | 否 |
2 | errors and warnings. | 否 |
3 | errors,warnings,and notes.the server logs aborted connections and access-denied errors for new connection attempts | 是 |
25 Error log 文件切割
If you flush the error log using FLUSH ERROR LOGS,FLUSH LOGS,or mysqladmin flush-logs,the server closes and reopens any error log file to which it is writing. To rename an error log file,do so manually before flushing. Flushing the logs then opens a new file with the original file name. For example,assuming a log file name of host_name.err,to rename the file and create a new one,use the following commands:
mv host_name.err host_name.err-old mysqladmin flush-logs mv host_name.err-old backup-directory
---应注意文件Owner,防止没有权限写操作
26 密码在general query log 中的体现
Passwords in statements written to the general query log are rewritten by the server not to occur literally in plain text. Password rewriting can be suppressed for the general query log by starting the server with the --log-raw option. This option may be useful for diagnostic purposes,to see the exact text of statements as received by the server,but for security reasons is not recommended for production use. --P853
27 binlog文件大于定义的max_binlog_size的情况
A binary log file may become larger than max_binlog_size if you are using large transactions because a transaction is written to the file in one piece,never split between files.
28 关于参数binlog_cache_size的解读
binlog_cache_size:当事务开始时,MySQL会分配一个binlog_cache_size大小的缓冲区(默认32K)给session用于存储二进制日志的缓存。如果事务大于binlog_cache_size,线程将打开一个 临时文件 用于存储事务(默认 /tmp 下,参照参数tmpdir),当线程结束时,临时文件会自动删除。
29 关于参数 binlog_error_action的解读
binlog_error_action:默认值为ABORT_SERVER,会使MySQL在写binlog遇到严重错误时直接退出(即Crash动作),比如磁盘满了,文件系统不可写入等。在ABORT_SERVER选项下,binlog和从库都是安全的,这是官方选择此默认值的原因。
30.MySQL单条记录最大长度限制
Row Size Limits The maximum row size for a given table is determined by several factors: The internal representation of a MySQL table has a maximum row size limit of 65,535 bytes,even if the storage engine is capable of supporting larger rows. BLOB and TEXT columns only contribute 9 to 12 bytes toward the row size limit because their contents are stored separately from the rest of the row.
MySQL Server 层的限制比较宽,一条记录不要超过65535个字节即可。也就是说,即使你的存储引擎支持更大的行长度,但是MYSQL 依然限制 Row size为65535;
BLOB and TEXT 这两种类型字段只占用行存储的9-12个字节,其他的内容分开存储。
31.InnoDB存储引擎下Row的长度限制
InnoDB关于Row的长度限制相对严格,一条记录的长度,不能超过innodb_page_size大小的一半(实际上还会略小,因为需要扣除页中关于页及记录的元数据信息)。如果页的大小是MySQL官方默认的16K,那么此时的单条记录的长度不能超过8126Byte。InnoDB是以B+树来组织数据的,所以InnoDB一个页至少包含两行数据(否在数据结构会退化成单链表)。
32.VARCHAR 类型字段最多能存储的字符数
在utf8mb4 编码中,字符的最大编码长度是4,比如中文;所以为了保证存储的字符串实际存储空间小于65535字节,字符串长度不能大于 floor(65535/4)=16383。
在latin1 编码字符集中,VARCHAR 类型字段最多能存储65533 个字符;
在utf8 编码字符集中,VARCHAR 类型字段最多能存储21844 个字符;
在utf8mb4 编码字符集中,VARCHAR 类型字段最多能存储16383 个字符;
33.index key 的最大长度限制
Both DYNAMIC and COMPRESSED row formats support index key prefixes up 3072 bytes. This feature is controlled by the innodb_large_prefix configuration option,which is enabled by default.
在DYNAMIC and COMPRESSED 行格式下默认支持索引长度不能超过3072字节.3072字节除以 utf8mb4 的最大编码长度4字节,在主键字段上长度上限应该是768;在utf8 编码字符集中,字符的最大编码长度是3字节,比如中文;所以如果 name作为主键,这个字段字符长度不能超过 3072/3=1024。
34.字段个数的限制
单表有多少个列也是有限制的:(1)Server层规定一个表的字段个数最多为4096个;(2)InnoDB层规定一个表的字段个数最多为1017个。
35.设置账号的过期时间
create user test@'%' identified by XXXXX' password expire interval 90 day; alter ; # 禁用过期,永久不过期: ' password expire never; ' password expire never;
36 row-level locking and InnoDB storage engine
InnoDB tables use row-level locking so that multiple sessions and applications can read from and write to the same table simultaneously,without making each other wait or producing inconsistent results. For this storage engine,avoid using the LOCK TABLES statement,because it does not offer any extra protection,but instead reduces concurrency. The automatic row-level locking makes these tables suitable for your busiest databases with your most important data,while also simplifying application logic since you do not need to lock and unlock tables. Consequently,the InnoDB storage engine is the default in MySQL.
MySQL uses table locking (instead of page,row,or column locking) for all storage engines except InnoDB. The locking operations themselves do not have much overhead. But because only one session can write to a table at any one time,for best performance with these other storage engines,use them primarily for tables that are queried often and rarely inserted into or updated.
----个人学习总结笔记,可能比较粗糙,观者见谅。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。