InnoDB存储引擎和大多数数据库一样（如Oracle和Microsoft SQL Server数据库），记录是以行的形式存储的。这意味着页中保存着表中一行行的数据。到MySQL 5.1时，InnoDB存储引擎提供了Compact和Redundant两种格式来存放行记录数据，Redundant是为兼容之前版本而保留的，如果你阅读过InnoDB的源代码，会发现源代码中是用PHYSICAL RECORD（NEW STYLE）和PHYSICAL RECORD（OLD STYLE）来区分两种格式的。MySQL 5.1默认保存为Compact行格式。你可以通过命令SHOW TABLE STATUS LIKE 'table_name'来查看当前表使用的行格式，其中row_format就代表了当前使用的行记录结构类型。例如：  use mysql;  show table status like 'user'\G   数据库实例的一个作用就是读取页中存放的行记录。如果我们知道规则，那么也可以读取其中的记录，如之前的py_innodb_page_info工具。下面将具体分析各格式存放数据的规则。  回到顶部  Compact行记录格式 Compact行记录是在MySQL 5.0时被引入的，其设计目标是能高效存放数据。简单来说，如果一个页中存放的行数据越多，其性能就越高。Compact行记录以如下方式进行存储：    Compact行格式的首部是一个非NULL变长字段长度列表，而且是按照列的顺序逆序放置的。当列的长度小于255字节，用1字节表示，若大于255个字节，用2个字节表示，变长字段的长度最大不可以超过2个字节（这也很好地解释了为什么MySQL中varchar的最大长度为65 535，因为2个字节为16位，即216=1=65 535）。第二个部分是NULL标志位，该位指示了该行数据中是否有NULL值，用1表示。该部分所占的字节应该为bytes。接下去的部分是为记录头信息（record header），固定占用5个字节（40位），每位的含义见下表4-1。最后的部分就是实际存储的每个列的数据了，需要特别注意的是，NULL不占该部分任何数据，即NULL除了占有NULL标志位，实际存储不占有任何空间。另外有一点需要注意的是，每行数据除了用户定义的列外，还有两个隐藏列，事务ID列和回滚指针列，分别为6个字节和7个字节的大小。若InnoDB表没有定义Primary Key，每行还会增加一个6字节的RowID列。   下面用一个具体事例来分析Compact行记录的内部结构：  create table mytest (  　　t1 varchar(10),  　　t2 varchar(10),  　　t3 char(10),  　　t4 varchar(10)  ) engine=innodb charset=latin1 row_format=compact;  insert into mytest values('a','bb','bb','ccc');   insert into mytest values('d','ee','ee','fff');   insert into mytest values('d',NULL,NULL,'fff');   select * from mytest\G;   创建了mytest表，有4个列，t1、t2、t4都为varchar变长字段类型，t3为固定长度类型char。接着我们插入了3条有代表性的数据，接着打开mytest.ibd（启用了innodb_file_per_table，若你没有启用该选项，请打开默认的共享表空间文件ibdata1）。在Windows下，可以选择用UltraEdit打开该二进制文件（在Linux环境下，使用hexdump -C -v mytest.ibd＞mytest.txt即可），打开mytest.txt文件，找到如下内容：   0000c070 73 75 70 72 65 6d 75 6d 03 02 01 00 00 00 10 00|supremum…… 0000c080 2c 00 00 00 2b 68 00 00 00 00 00 06 05 80 00 00|，……+h…… 0000c090 00 32 01 10 61 62 62 62 62 20 20 20 20 20 20 20|.2..abbbb 0000c0a0 20 63 63 63 03 02 01 00 00 00 18 00 2b 00 00 00|ccc……+…… 0000c0b0 2b 68 01 00 00 00 00 06 06 80 00 00 00 32 01 10|+h……2.. 0000c0c0 64 65 65 65 65 20 20 20 20 20 20 20 20 66 66 66|deeeefff 0000c0d0 03 01 06 00 00 20 ff 98 00 00 00 2b 68 02 00 00|……+h…… 0000c0e0 00 00 06 07 80 00 00 00 32 01 10 64 66 66 66 00|……2..dfff. 该行记录从0000c078开始，若整理如下，相信你会有更好的理解： 03 02 01/*变长字段长度列表，逆序*/ 00/*NULL标志位，第一行没有NULL值*/ 00 00 10 00 2c/*记录头信息，固定5字节长度*/ 00 00 00 2b 68 00/*RowID我们建的表没有主键，因此会有RowID*/ 00 00 00 00 06 05/*TransactionID*/ 80 00 00 00 32 01 10/*Roll Pointer*/ 61/*列1数据'a'*/ 62 62/*列2'bb'*/ 62 62 20 20 20 20 20 20 20 20/*列3数据'bb'*/ 63 63 63/*列4数据'ccc'*/ 现在第一行数据就展现在我们眼前了。需要注意的是，变长字段长度列表是逆序存放的，03 02 01，而不是01 02 03。还需要注意的是InnoDB每行有隐藏列。同时可以看到，固定长度char字段在未填充满其长度时，会用0x20来进行填充。再来分析一下，记录头信息的最后4个字节代表next_recorder，0x6800代表下一个记录的偏移量，当前记录的位置+0x6800就是下一条记录的起始位置。所以InnoDB存储引擎在页内部是通过一种链表的结构来串联各个行记录的。  第二行我将不做整理，除了RowID不同外，它和第一行大同小异，有兴趣的读者可以用上面的方法自己试试。  现在我们关注有NULL值的第三行：  03 01/*变长字段长度列表，逆序*/  06/*NULL标志位，第三行有NULL值*/  00 00 20 ff 98/*记录头信息*/  00 00 00 2b 68 02/*RowID*/  00 00 00 00 06 07/*TransactionID*/  80 00 00 00 32 01 10/*Roll Pointer*/  64/*列1数据'd'*/  66 66 66/*列4数据'fff'*/  第三行有NULL值，因此NULL标志位不再是00而是06了，转换成二进制为00000110，为1的值即代表了第2列和第3列的数据为NULL，在其后存储列数据的部分，我们会发现没有存储NULL，只存储了第1列和第4列非NULL的值。这个例子很好地说明了：不管是char还是varchar类型，NULL值是不占用存储空间的。  回到顶部  Redundant行记录格式 Redundant是MySQL 5.0版本之前InnoDB的行记录存储方式，MySQL 5.0支持Redundant是为了向前兼容性。Redundant行记录以如下方式存储：   从上图可以看到，不同于Compact行记录格式，Redundant行格式的首部是一个字段长度偏移列表，同样是按照列的顺序逆序放置的。当列的长度小于255字节，用1字节表示；若大于255个字节，用2个字节表示。第二个部分为记录头信息（record header），不同于Compact行格式，Redundant行格式固定占用6个字节（48位），每位的含义见表4-2。从表中可以看到，n_fields值代表一行中列的数量，占用10位，这也很好地解释了为什么MySQL一个行支持最多的列为1023。另一个需要注意的值为1byte_offs_flags，该值定义了偏移列表占用1个字节还是2个字节。最后的部分就是实际存储的每个列的数据了。   创建一张和mytest内容完全一样、但行格式为Redundant的表mytest2  create table mytest2 engine=innodb row_format=redundant as (select * from mytest);  show table status like 'mytest2'\G  select * from mytest2\G  现在row_format变为Redundant。同样，通过hexdump将表空间mytest2.ibd导出到文本文件mytest2.txt。打开文件，找到类似如下行：  0000c070 08 03 00 00 73 75 70 72 65 6d 75 6d 00 23 20 16|……supremum.#. 0000c080 14 13 0c 06 00 00 10 0f 00 ba 00 00 00 2b 68 0b|……+h. 0000c090 00 00 00 00 06 53 80 00 00 00 32 01 10 61 62 62|……S……2..abb 0000c0a0 62 62 20 20 20 20 20 20 20 20 63 63 63 23 20 16|bb ccc#. 0000c0b0 14 13 0c 06 00 00 18 0f 00 ea 00 00 00 2b 68 0c|……+h. 0000c0c0 00 00 00 00 06 53 80 00 00 00 32 01 1e 64 65 65|……S……2..dee 0000c0d0 65 65 20 20 20 20 20 20 20 20 66 66 66 21 9e 94|ee fff！.. 0000c0e0 14 13 0c 06 00 00 20 0f 00 74 00 00 00 2b 68 0d|……t……+h. 0000c0f0 00 00 00 00 06 53 80 00 00 00 32 01 2c 64 00 00|……S……2.，d.. 0000c100 00 00 00 00 00 00 00 00 66 66 66 00 00 00 00 00|……fff……  整理可以得到如下内容： 23 20 16 14 13 0c 06/*长度偏移列表，逆序*/ 00 00 10 0f 00 ba/*记录头信息，固定6个字节*/ 00 00 00 2b 68 0b/*RowID*/ 00 00 00 00 06 53/*TransactionID*/ 80 00 00 00 32 01 10/*Roll Point*/ 61/*列1数据'a'*/ 62 62/*列2数据'bb'*/ 62 62 20 20 20 20 20 20 20 20/*列3数据'bb'Char类型*/ 63 63 63/*列4数据'ccc'*/ 23 20 16 14 13 0c 06，逆转为06，0c，13，14，16，20，23。分别代表第一列长度6，第二列长度6（6+6=0x0C），第三列长度为7（6+6+7=0x13），第四列长度1（6+6+7+1=0x14），第五列长度2（6+6+7+1+2=0x16），第六列长度10（6+6+7+1+2+10=0x20），第七列长度3（6+6+7+1+2+10+3=0x23）。  记录头信息中应该注意48位中22～32位，为0000000111，表示表共有7个列（包含了隐藏的3列），接下去的33位为1，代表偏移列表为一个字节。  后面的信息就是实际每行存放的数据了，这与Compact行格式大致相同。  请注意是大致相同，因为如果我们来看第三行，会发现对于NULL的处理两者是不同的。  21 9e 94 14 13 0c 06/*长度偏移列表，逆序*/  00 00 20 0f 00 74/*记录头信息，固定6个字节*/  00 00 00 2b 68 0d/*RowID*/  00 00 00 00 06 53/*TransactionID*/  80 00 00 00 32 01 10/*Roll Point*/  64/*列1数据'a'*/  00 00 00 00 00 00 00 00 00 00/*列3数据NULL*/  66 66 66/*列4数据'fff'*/  这里与之前Compact行格式有着很大的不同了，首先来看长度偏移列表，我们逆序排列后得到06 0c 13 14 94 9e 21，前4个值都很好理解，第5个NULL变为了94，接着第6个列char类型的NULL值为9e（94+10=0x9e），之后的21代表14+3=0x21。可以看到对于varchar的NULL值，Redundant行格式同样不占用任何存储空间，因而char类型的NULL值需要占用空间。  当前表mytest2的字符集为Latin1，每个字符最多只占用1个字节。若这里将表mytest2的字符集转换为utf8，第三列char固定长度类型就不再是只占用10个字节了，而是10×3=30个字节，Redundant行格式下char固定字符类型将会占据可能存放的最大值字节数。  回到顶部  Compressed与Dynamic行记录格式 InnoDB Plugin引入了新的文件格式（file format，可以理解为新的页格式），对于以前支持的Compact和Redundant格式将其称为Antelope文件格式，新的文件格式称为Barracuda。Barracuda文件格式下拥有两种新的行记录格式Compressed和Dynamic两种。新的两种格式对于存放BLOB的数据采用了完全的行溢出的方式，在数据页中只存放20个字节的指针，实际的数据都存放在BLOB Page中，而之前的Compact和Redundant两种格式会存放768个前缀字节。  下图是Barracuda文件格式的溢出行：   Compressed行记录格式的另一个功能就是，存储在其中的行数据会以zlib的算法进行压缩，因此对于BLOB、TEXT、VARCHAR这类大长度类型的数据能进行非常有效的存储。   原文：https://blog.csdn.net/qq_40026782/article/details/99544653?spm=1001.2014.3001.5502 

 1、查询是否锁表  show OPEN TABLES where In_use > 0;  查询到相对应的进程 === 然后 kill    id  2、查询进程      show processlist     补充：  查看正在锁的事务  SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;      查看等待锁的事务  SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;         -- 查出死锁进程：SHOW PROCESSLIST  -- 杀掉进程          KILL 420821;  其它关于查看死锁的命令：  1：查看当前的事务 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;  2：查看当前锁定的事务  SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;  3：查看当前等锁的事务 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;  -- 查询死锁详情  SELECT r.trx_id waiting_trx_id,r.trx_mysql_thread_id waiting_thread, TIMESTAMPADD(SECOND,r.trx_wait_started,CURRENT_TIMESTAMP) wait_time, r.trx_query waiting_query, l.lock_table waiting_table_lock, b.trx_id blocking_trx_id,b.trx_mysql_thread_id blocking_thread, SUBSTRING(p.`HOST`,1,INSTR(p.`HOST`,':')-1) blocking_host, SUBSTRING(p.`HOST`,INSTR(p.`HOST`,':')+1) blocking_port, IF(p.COMMAND ='Sleep',p.TIME,0) idle_in_trx, b.trx_query blocking_query from information_schema.INNODB_LOCK_WAITS w INNER JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_lock_id INNER JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id INNER JOIN information_schema.INNODB_LOCKS l ON l.lock_id = w.requested_lock_id LEFT JOIN information_schema.`PROCESSLIST` p ON p.id = b.trx_mysql_thread_id ORDER BY wait_time desc;        1 show processlist;    SHOW PROCESSLIST显示哪些线程正在运行。您也可以使用mysqladmin processlist语句得到此信息。如果您有SUPER权限，您可以看到所有线程。否则，您只能看到您自己的线程（也就是，与您正在使用的MySQL账户相关的线程）。如果有线程在update或者insert 某个表，此时进程的status为updating 或者 sending data。     如果您得到“too many connections”错误信息，并且想要了解正在发生的情况，本语句是非常有用的。MySQL保留一个额外的连接，让拥有SUPER权限的账户使用，以确保管理员能够随时连接和检查系统（假设您没有把此权限给予所有的用户）。     Status  含义  Checking table  正在检查数据表（这是自动的）。  Closing tables  正在将表中修改的数据刷新到磁盘中，同时正在关闭已经用完的表。这是一个很快的操作，如果不是这样的话，就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。  Connect Out  复制从服务器正在连接主服务器。  Copying to tmp table on disk  由于临时结果集大于tmp_table_size，正在将临时表从内存存储转为磁盘存储以此节省内存。  Creating tmp table  正在创建临时表以存放部分查询结果。  deleting from main table  服务器正在执行多表删除中的第一部分，刚删除第一个表。  deleting from reference tables  服务器正在执行多表删除中的第二部分，正在删除其他表的记录。  Flushing tables  正在执行FLUSH TABLES，等待其他线程关闭数据表。  Killed  发送了一个kill请求给某线程，那么这个线程将会检查kill标志位，同时会放弃下一个kill请求。MySQL会在每次的主循环中检查kill标志位，不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了，那么kill请求会在锁释放时马上生效。  Locked  被其他查询锁住了。  Sending data  正在处理SELECT查询的记录，同时正在把结果发送给客户端。  Sorting for group  正在为GROUP BY做排序。  Sorting for order  正在为ORDER BY做排序。  Opening tables  这个过程应该会很快，除非受到其他因素的干扰。例如，在执ALTER TABLE或LOCK TABLE语句行完以前，数据表无法被其他线程打开。正尝试打开一个表。  Removing duplicates  正在执行一个SELECT DISTINCT方式的查询，但是MySQL无法在前一个阶段优化掉那些重复的记录。因此，MySQL需要再次去掉重复的记录，然后再把结果发送给客户端。  Reopen table  获得了对一个表的锁，但是必须在表结构修改之后才能获得这个锁。已经释放锁，关闭数据表，正尝试重新打开数据表。  Repair by sorting  修复指令正在排序以创建索引。  Repair with keycache  修复指令正在利用索引缓存一个一个地创建新索引。它会比Repair by sorting慢些。  Searching rows for update  正在讲符合条件的记录找出来以备更新。它必须在UPDATE要修改相关的记录之前就完成了。  Sleeping  正在等待客户端发送新请求。  System lock  正在等待取得一个外部的系统锁。如果当前没有运行多个mysqld服务器同时请求同一个表，那么可以通过增加--skip-external-locking参数来禁止外部系统锁。  Upgrading lock  INSERT DELAYED正在尝试取得一个锁表以插入新记录。  Updating  正在搜索匹配的记录，并且修改它们。  User Lock  正在等待GET_LOCK()。  Waiting for tables  该线程得到通知，数据表结构已经被修改了，需要重新打开数据表以取得新的结构。然后，为了能的重新打开数据表，必须等到所有其他线程关闭这个表。以下几种情况下会产生这个通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。  waiting for handler insert  INSERT DELAYED已经处理完了所有待处理的插入操作，正在等待新的请求。     大部分状态对应很快的操作，只要有一个线程保持同一个状态好几秒钟，那么可能是有问题发生了，需要检查一下。还有其他的状态没在上面中列出来，不过它们大部分只是在查看服务器是否有存在错误是才用得着。     2 show full processlist;    show processlist;只列出前100条，如果想全列出请使用show full processlist;     3 show open tables;    这条命令能够查看当前有那些表是打开的。In_use列表示有多少线程正在使用某张表，Name_locked表示表名是否被锁，这一般发生在Drop或Rename命令操作这张表时。所以这条命令不能帮助解答我们常见的问题：当前某张表是否有死锁，谁拥有表上的这个锁等。     show open tables from database;         4 show status like ‘%lock%’    查看服务器状态。         5 show engine innodb statusG;    MySQL 5.1之前的命令是：show innodbstatusG;，MySQL 5.5使用上面命令即可查看innodb引擎的运行时信息。         6 show variables like ‘%timeout%’;    查看服务器配置参数。        ———————————————— 原文链接：https://blog.csdn.net/qq_40026782/article/details/100518617 

记录MySQL 5.5上，优化器进行cost计算的方法。第一篇： 单表的cost计算数据结构：1. table_share: 包含了表的元数据，其中索引部分：key_info：一个key的结构体，代表一个索引，包含了：key_length：key的长度key_parts：key一共有多少个columnkey_part：key中具体的columnrec_per_key：相同的key平均有几条记录例如：123456(gdb) p (table->s->key_info->name)     $16 = 0x8ca0ffbd "PRIMARY"(gdb) p (table->s->key_info->key_parts)     $17 = 1(gdb) p (table->s->key_info->rec_per_key)     $18 = (ulong *) 0x8ca0ffe82. JOIN:    mysql_select函数中，创建了 new JOIN(thd, fields, select_options, result)对象，包含了当前查询的所有组件和各种转换结果，其中 ：prepare：进行一些等价交换之类的变化optimize：选择join的方式和access pathexec：根据执行计划运行查询3. join_tab:    包含了一个table访问的cost等一些信息，经过优化后，填充这个结构体cost的计算方法cost = cpu cost + io costcpu cost：server层对返回的记录数的compare时间io cost：引擎层根据扫描记录的记录数计算cost统计信息这里用到了两部分统计信息：1. server层的统计信息，保存在table_share中。包括：key_lengthrec_per_keyblock_size等2. innodb层的统计信息，包括：stat_n_rowsstat_clustered_index_sizestat_sum_of_other_index_size主要函数调用make_join_statistics：--update_ref_and_keys: 添加可以使用的索引。--get_quick_record_count:----test_quick_select: 评估每一个join table查询得到的记录数，其中比较不同index的cost, 返回的记录数，选择最优的那个。choose plan：选择join的顺序实验过程123456789CREATE TABLE `xpchild` (  `id` int(11) NOT NULL,  `name` varchar(100) DEFAULT NULL,  `c1` int(11) DEFAULT NULL,  `c2` int(11) DEFAULT NULL,  PRIMARY KEY (`id`),  KEY `xpchild_name` (`name`),  KEY `xpchild_id_c1` (`id`,`c1`)) ENGINE=InnoDB DEFAULT CHARSET=latin1实验1： 单值查询1explain select * from xpchild where id =100;函数调用栈：make_join_statistics：    table->quick_condition_rows= table->file->stats.records;   if (s->type == JT_SYSTEM || s->type == JT_CONST)   s->found_records=s->records=s->read_time=1; s->worst_seeks=1.0;结论：单key的查询，join_tab的type=JT_CONST，索引record和read time都是1；最终得到的join->best_read=1.0;实验2： 范围查询explain select * from xpchild where id > 100;step1：update_ref_and_keys: 一共得到两个possible index，step2：test_quick_select    1. 计算全表扫描的cost：innodb全表扫描的io cost：innodb的io cost： s->read_time=(ha_rows) s->table->file->scan_time();innodb scan time：prebuilt->table->stat_clustered_index_size等于innodb这张表的聚簇索引的page个数，本身innodb就是聚簇索引表，这里计算的io cost=16(gdb) p s->read_time$7 = 16MySQL server的cpu cost：scan_time= (double) records / TIME_FOR_COMPARE + 1;(gdb) p scan_time$16 = 1359.4000000000001总的cost：read_time= (double) head->file->scan_time() + scan_time + 1.1;(gdb) p read_time$18 = 1376.5继续函数栈：根据possible index，生成sel_tree;get_best_group_min_max: 这里没有使用到get_key_scans_params：根据sel_tree找到更好的cost2. 计算full index的cost      find_shortest_key: 在覆盖索引中选择length最短的那个。      get_index_only_read_time：这里如果有覆盖索引（covering index）那么就会计算此覆盖索引的cost。      full index scan的计算方法：1234uint keys_per_block= (param->table->file->stats.block_size/2/                      (param->table->key_info[keynr].key_length+                       param->table->file->ref_length) + 1);read_time=((double) (records+keys_per_block-1)/(double) keys_per_block);     这里假设：一个块中，只使用了一半的空间写入数据，     如果计算的key_read_time > read_time, 则read_time= key_read_time，从此不再使用全表扫描。3. pk 索引计算的cost进入get_key_scans_params函数：选择比传入的read_time小的cost的执行计划，生成一个TRP_RANGE对象返回。step1: 评估范围扫描的记录数（check_quick_select）check_quick_keys：根据key，min，max值来评估记录数，并把records记录到table->quick_rows[key]中，以便后续需要。12(gdb) p *min_key$82 = 100 'd'ha_innobase::records_in_range: innodb引擎根据min和max值来评估记录数。    计算方法：innodb对b_tree中范围确定的page的个数和record_per_page进行计算，当评估>all_record/2时，就取all_record/2。12(gdb) p records$112 = 3396step 2: 计算cost根据pk range估算的records=3396，调整table->quick_condition_rows从全表的6792到现在的3396。计算cost：12345cpu_cost= (double) found_records / TIME_FOR_COMPARE;cpu_cost= 679.20000000000005<br>io_cost = param->table->file->read_time(keynr,param->range_count,found_records);<br>found_read_time = cpu_cost + io_cost + 0.01found_read_time = 683.74750000000006这样，通过pk扫描的cost远小于前面第一阶段的全表扫描的代价。4. 计算普通索引的cost     因为都可以使用前导列进行查询，查询的效率的差别在于非主键索引需要回到聚簇索引中查询非索引列。所以，innodb返回的found_rows=6556（包含了扫描索引xpchild_id_c1 和primary key的）, 所以最终计算的cost大于使用pk的cost。      最终计算得到的cost=7868.21 远高于pk索引的cost。结论： 最终选择了pk的索引进行range扫描原文：https://blog.csdn.net/qq_40026782/article/details/105773496?spm=1001.2014.3001.5502

 1、查询一张表的详细信息(包括字段注释,字段名称,类型等).  select * from information_schema.columns where table_schema ='my_db'  and table_name = 'auth_user';     2、Mysql是否开启binlog：show variables like 'log_bin';  3、查看日志：show variables like 'log_%';  4、mysql删除日志（解决阿里云RDS日志无法删除问题）不太建议使用，但是阿里云不给删日志，空间占用太多了，所以就直接删了：  RESET MASTER;//删除所有binlog日志，新日志编号从头开始  如果可以权限比较充足，建议使用下面删除语句：   purge binary logs to 'mysql-bin.000079';   show binary logs;  Mysql中如何查看慢查询以及查看线程  SELECT * , CONVERT(sql_text USING utf8)  AS userNam    FROM  mysql.slow_log where  start_time > '2019-11-05 10'    -- and query_time >'00:01:00.000000'  ORDER BY query_time DESC ;    查看表是否被锁： 直接在mysql命令行执行:show engine innodb status\G。 查看造成死锁的sql语句，分析索引情况，然后优化sql. 然后show processlist,查看造成死锁占用时间长的sql语句。 show status like ‘%lock%。   查看表被锁状态和结束死锁步骤： 1.查看表被锁状态 show OPEN TABLES where In_use > 0; 这个语句记录当前锁表状态  2.查询进程 show processlist 查询表被锁进程 查询到相应进程kill id 3.分析锁表的SQL 分析相应SQL，给表加索引，常用字段加索引，表关联字段加索引   查看正在锁的事物： SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS. 查看等待锁的事物： SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS.  ————————————————  原文链接：https://blog.csdn.net/qq_40026782/article/details/93622577 

例如对于只有100条数据的MySQL表是否有必要加索引，这取决于具体的使用场景。以下是一些考虑因素：查询频率：如果该字段是查询条件中经常使用的，且查询频率较高，那么加索引可以提高查询效率。数据唯一性：如果该字段的值具有较高唯一性，即不同值的数量接近于表中记录的数量，那么索引的选择性会很高，加索引会更加有效。查询优化：如果您的查询可以通过索引覆盖来避免访问原始数据，那么即使是小表，加索引也是有益的。维护成本：虽然索引可以提高查询性能，但它也会增加数据插入、更新和删除时的维护成本。因此，如果表数据量不大，且更新频繁，可能不需要加索引。总的来说，如果该字段是查询条件中经常使用的、数据唯一性高、查询优化明显，并且维护成本不是问题，那么加索引是有必要的。反之，如果这个字段很少作为查询条件，或者数据唯一性不高，那么加索引可能收益不大。在实际操作中，建议根据具体的业务需求和数据库使用情况来决定是否加索引。

INSERT INTO ... ON DUPLICATE KEY UPDATE语句是MySQL中的一种特殊插入方式，用于在插入数据时判断是否存在重复的主键或唯一索引，如果存在则更新数据，否则插入新数据。这种操作可以简化代码，避免先查询再插入或更新的繁琐过程。具体语法如下：INSERT INTO 表名 (列1, 列2, 列3, ...) VALUES (值1, 值2, 值3, ...) ON DUPLICATE KEY UPDATE 列1 = VALUES(列1), 列2 = VALUES(列2), 列3 = VALUES(列3);其中：表名：要插入数据的表名。列1, 列2, 列3, ...：要插入或更新的列名。值1, 值2, 值3, ...：要插入的值。ON DUPLICATE KEY UPDATE：表示当主键或唯一索引冲突时，执行更新操作。列1 = VALUES(列1), 列2 = VALUES(列2), 列3 = VALUES(列3)：表示更新的列及其对应的新值，使用VALUES()函数引用插入的数据。举个例子，假设有一个名为students的表，包含id（主键）、name和age三个字段，现在需要插入或更新一条数据：INSERT INTO students (id, name, age) VALUES (1, '张三', 18) ON DUPLICATE KEY UPDATE name = VALUES(name), age = VALUES(age);这条语句会尝试插入一条id为1、name为'张三'、age为18的数据。如果表中已经存在id为1的数据，那么会更新该条数据的name和age字段为新的值。自增主键情况如果表的主键是自增的（auto_increment），那么INSERT INTO ... ON DUPLICATE KEY UPDATE语句会稍微有所不同，因为自增主键的值通常是由数据库自动生成的，不需要在插入时指定。在这种情况下，你通常只需要在VALUES部分提供其他非自增字段的值。MySQL会自动处理自增主键字段，当插入新记录时，它会自动分配一个新的自增值；当更新现有记录时，自增主键的值不会改变，因为它是记录的唯一标识。例如，假设有一个名为students的表，包含一个自增主键id、name和age字段。你想要插入或更新一条学生记录，可以这样做：INSERT INTO students (name, age) VALUES ('张三', 18) ON DUPLICATE KEY UPDATE name = VALUES(name), age = VALUES(age);在这个例子中，id字段没有在INSERT INTO语句中明确指定，因为它是自增的。当插入新记录时，MySQL会自动为id字段分配一个新的自增值。如果存在id相同的记录，那么name和age字段会被更新为新的值。需要注意的是，ON DUPLICATE KEY UPDATE语句依赖于表中的主键或唯一索引。如果没有定义主键或唯一索引，那么这个语句将无法正常工作，因为没有唯一的记录标识来判断是否存在重复。因此，在使用ON DUPLICATE KEY UPDATE语句之前，请确保表有合适的主键或唯一索引约束。

MySQL架构与历史引言MySQL是一个广泛使用的关系型数据库管理系统（RDBMS），以其高性能、可靠性和易用性而闻名。自1995年首次发布以来，MySQL已经成为了许多企业和个人项目的首选数据库解决方案。本文将探讨MySQL的架构和历史，以便更好地了解这个强大的数据库系统。MySQL历史MySQL的历史可以追溯到1995年，当时Michael Widenius和David Axmark共同创建了MySQL AB公司，并发布了第一个MySQL版本。从那时起，MySQL不断发展壮大，逐渐成为了最受欢迎的开源数据库之一。在MySQL的发展过程中，有几个重要的里程碑值得一提：2000年：MySQL发布了3.23版本，引入了许多新功能，如全文搜索和存储过程。2004年：MySQL 5.0版本的发布标志着MySQL进入了新的发展阶段，引入了视图、触发器、存储过程和事件调度器等高级功能。2008年：Sun Microsystems收购了MySQL AB，将MySQL作为其开源软件战略的重要组成部分。不久后，Oracle Corporation收购了Sun Microsystems，从而成为MySQL的新东家。2020年代：MySQL继续发展，不断优化性能和功能，以适应现代应用程序的需求。MySQL架构MySQL的架构可以分为几个主要组件：1. 连接层连接层负责处理客户端与MySQL服务器之间的连接。它支持多种协议，如TCP/IP、Unix套接字和命名管道，以便客户端可以通过不同的方式与MySQL服务器通信。2. 服务层服务层是MySQL架构的核心，负责处理来自客户端的SQL请求。它包括解析器、优化器、查询缓存和执行引擎等组件。解析器：解析器负责将SQL查询转换为内部表示形式，以便后续处理。优化器：优化器负责为查询选择最佳的执行计划，以提高查询性能。查询缓存：查询缓存存储已执行查询的结果，以便在相同查询再次出现时快速返回结果。但需要注意的是，在某些情况下，查询缓存可能会降低性能，因此在高并发环境下可能需要禁用它。执行引擎：执行引擎负责执行查询并返回结果。MySQL支持多种存储引擎，如InnoDB、MyISAM和Memory等，每种存储引擎都有其特定的优势和适用场景。3. 存储引擎层存储引擎层负责数据的存储和检索。MySQL的灵活性之一在于其支持多种存储引擎，用户可以根据需要选择合适的存储引擎。例如，InnoDB提供了事务支持和行级锁定，适用于需要高并发写入的应用场景；而MyISAM则提供了全文搜索和高速读取功能，适用于读密集型的应用场景。4. 数据存储层数据存储层负责将数据存储在磁盘上。MySQL使用文件系统或原始磁盘分区来存储数据。为了提高性能，MySQL还支持将数据分区存储在不同的物理磁盘上。总结MySQL的架构和历史展示了其作为一个强大、可靠和易用的数据库系统的演变过程。通过了解MySQL的架构，我们可以更好地理解其工作原理，并根据实际需求进行优化。在未来，随着技术的不断发展，MySQL将继续适应新的挑战，为用户提供更高效的数据库解决方案。

查询当前所有的表SQL> select * from tab;SQL> select * from cat where table_type=’TABLE’;//可能会有viewSQL>select * from user_tables;mysql> show tables;c:/mysql/bin>mysqlshow 库名显示当前连接用户（库）SQL> show usermysql> connect查看帮助SQL> ?mysql> help显示表结构SQL> desc 表名SQL> describe 表名mysql> desc 表名;mysql> describe 表名;mysql> show columns from 表名;c:/mysql/bin>mysqlshow 库名 表名日期函数SQL> select sysdate from dual;mysql> select now();mysql> select sysdate();mysql> select curdate();mysql> select current_date;mysql> select curtime();mysql> select current_time;日期格式化SQL> select to_char(sysdate,'yyyy-mm-dd') from dual;SQL> select to_char(sysdate,'hh24-mi-ss') from dual;mysql> select date_format(now(),'%Y-%m-%d');mysql> select time_format(now(),'%H-%i-%S');日期函数（增加一个月）SQL> select to_char(add_months(to_date('20000101','yyyymmdd'),1),'yyyy-mm-dd') from dual;结果：2000-02-01SQL> select to_char(add_months(to_date('20000101','yyyymmdd'),5),'yyyy-mm-dd') from dual;结果：2000-06-01mysql> select date_add('2000-01-01',interval 1 month);结果：2000-02-01mysql> select date_add('2000-01-01',interval 5 month);结果：2000-06-01别名SQL> select 1 a from dual;SQL>select 1 as a from dual; //as可以省略mysql> select 1 as a;字符串截取函数SQL> select substr('abcdefg',1,5) from dual;SQL> select substr('abcdefg',1,5) from dual;结果：abcdemysql> select substring('abcdefg',2,3);结果：bcdmysql> select mid('abcdefg',2,3);结果：bcdmysql> select substring('abcdefg',2);结果：bcdefgmysql> select substring('abcdefg' from 2);结果：bcdefg另有SUBSTRING_INDEX(str,delim,count)函数返回从字符串str的第count个出现的分隔符delim之后的子串。如果count是正数，返回最后的分隔符到左边(从左边数) 的所有字符。如果count是负数，返回最后的分隔符到右边的所有字符(从右边数)。执行外部脚本命令SQL >@a.sql1：mysql> source a.sql2：c:/mysql/bin>mysql <a.sql3：c:/mysql/bin>mysql 库名 <a.sql导入、导出工具exp.exeexp73.exeimp.exeimp73.exemysqldump.exemysqlimport.exe改表名SQL> rename a to b;mysql> alter table a rename b;执行命令;<回车>/rrun;<回车>goegodistinct用法SQL> select distinct 列1 from 表1;SQL> select distinct 列1,列2 from 表1;mysql> select distinct 列1 from 表1;mysql> select distinct 列1,列2 from 表1;注释--/*与*/#--/*与*/当作计算器SQL> select 1+1 from dual;mysql> select 1+1;限制返回记录条数SQL> select * from 表名 where rownum<5;mysql> select * from 表名 limit 5;新建用户（库）SQL> create user 用户名 identified by 密码;mysql> create database 库名;删用户（库）SQL> drop user 用户名;mysql> drop database 库名;查询索引SQL> select index_name,table_name from user_indexes;mysql> show index from 表名 [FROM 库名];通配符“%”和“_”“%”和“_”SQL语法SELECT selection_list 选择哪些列FROM table_list 从何处选择行WHERE primary_constraint 行必须满足什么条件GROUP BY grouping_columns 怎样对结果分组HAVING secondary_constraint 行必须满足的第二条件ORDER BY sorting_columns 怎样对结果排序SELECT selection_list 选择哪些列FROM table_list 从何处选择行WHERE primary_constraint 行必须满足什么条件GROUP BY grouping_columns 怎样对结果分组HAVING secondary_constraint 行必须满足的第二条件ORDER BY sorting_columns 怎样对结果排序LIMIT count 结果限定自动增长的数据类型处理create sequence myseq increment by 1 start with 1 maxvalue 99999; 主键列上加auto_increment

 一、数据库的操作 1. 创建数据库 语法：CREATE DATABASE [IF NOT EXISTS] db_name [create_specification [, create_specification] ...]      create_specification:     [DEFAULT] CHARACTER SET charset_name     [DEFAULT] COLLATE collation_name 1 2 3 说明：  大写的表示关键字，mysql 不区分大小写，所以也可以用小写 [] 是可选项 CHARACTER SET: 指定数据库采用的字符集 COLLATE: 指定数据库字符集的校验规则 假设现在我们现在需要创建一个名为 d1 的数据库，首先我们先查看一下数据库，查看数据库：show databases;  下面开始创建 d1 数据库：create database d1;   如上，d1 数据库就创建好了。  注意：当我们创建数据库没有指定字符集和校验规则时，系统使用默认字符集：utf8，校验规则是：utf8_ general_ ci.  创建一个使用 utf8 字符集的 d2 数据库：create database d2 charset=utf8;  创建一个使用 utf8 字符集，并带校对规则的 d3 数据库：create database d3 charset=utf8 collate utf8_general_ci;  我们在前面也说过，创建一个数据库其实就是在 Linux 下创建一个目录，这里就不再重复介绍了。  2. 字符集和校验规则 当我们创建数据库的时候，有两个编码集：  数据库编码集 - - - 数据库未来存储数据所采用的编码集； 数据库校验集 - - - 支持数据库，进行字段比较使用的编码，本质也是一种读取数据库中数据所采用的编码格式； 所以数据库无论对数据做任何操作，都必须保证操作和编码必须是编码一致的。  字符集主要是控制用什么语言。比如 utf8 就可以使用中文。  （1）查看系统默认字符集以及校验规则         show variables like 'character_set_database';  # 默认字符集         show variables like 'collation_database';      # 检验规则  （2）查看数据库支持的字符集         show charset; 1 （3）查看数据库支持的字符集校验规则         show collation; 1 （4）校验规则对数据库的影响 不区分大小写 创建一个数据库，校验规则使用 utf8_ general_ ci (不区分大小写，即在检验的时候不严格匹配，不对大小写字母进行区分)          create database test1 collate utf8_general_ci; 1 随后我们需要使用这个数据库：use test1  然后我们为这个数据库创建一张表，并插入一些数据，创建表和插入的语法我们先不做介绍，后面再介绍；如下：  接下来我们对这个表的插入结果进行查看，注意，该表的校验方法是不进行区分大小写进行匹配的；所以我们先查看整个表的情况：select * from for_test;  接下来我们筛选出 a 这个字符：select * from for_test where name='a';  我们可以看到，数据库在匹配 a 这个字符的时候不进行大小写区分，无论大写还是小写都给我们显示出来了。  区分大小写 创建一个数据库，校验规则使用 utf8_ bin (区分大小写，校验时按照严格匹配的方式，区分大小写)  因为该数据库的检验规则为 utf8_ bin，进行区分大小写的方式进行严格匹配，所以筛选出来的字符 a 就是字符 a.  3. 操纵数据库 （1）查看数据库         show databases; 1  （2）显示创建的语句         show create database 数据库名;  MySQL 建议我们关键字使用大写，但是不是必须的； 数据库名字的反引号``,是为了防止使用的数据库名刚好是关键字 / * !40100 default… * / 这个不是注释，表示当前mysql版本大于4.01版本，就执行这句话； （3）修改数据库 语法：          ALTER DATABASE db_name         [alter_spacification [,alter_spacification]...] 1 2 alter_spacification: [DEFAULT] CHARACTER SET charset_name [DEFAULT] COLLATE collation_name  说明：对数据库的修改主要指的是修改数据库的字符集，校验规则。  假设将我们上面创建的 test1 数据库的字符集改成 gbk：alter database test1 charset=gbk;   test1 数据库的字符集就修改成了 gbk.  4. 数据库删除 语法：          DROP DATABASE [IF EXISTS] db_ name; 1 例如我们删掉我们前面建的 test2 数据库：drop database test2;  如下：   如上图，test2 数据库就被删除了。  执行删除之后的结果：  数据库内部看不到对应的数据库 对应的数据库文件夹被删除，级联删除，里面的数据表全部被删 5. 备份和恢复 （1）备份数据库 在备份数据库之前我们先需要退出 mysql.  语法：          mysqldump -P3306 -u root -p密码 -B 数据库名 > 数据库备份存储的文件路径 1 其中密码部分我们可以不在命令行输入，当我们执行这条命令的时候命令行会提示我们输入。  例如我们把 test1 库备份到文件中：mysqldump -P3306 -uroot -p -B test1 > /home/lmy/test1.sql   这时，可以打开看看 test1.sql 文件里的内容，其实把我们整个创建数据库，建表，导入数据的语句都装载这个文件中。  接下来我们进入 mysql 中，把这个数据库删掉：   如上图，test1 库就被我们删除了，接下来我们进行还原。  （2）还原 语法：          source 数据库备份的文件路径; 1 我们在 mysql 中输入指令：source /home/lmy/test1.sql; 即可在 mysql 中恢复 test1 库：   （3）拓展 如果备份的不是整个数据库，而是其中的一张表，怎么做？做法如下：          mysqldump -uroot -p 数据库名 表名1 表名2 > 备份文件路径 1 如果同时备份多个数据库，如下：          mysqldump -uroot -p -B 数据库名1 数据库名2 ... > 数据库存放路径 1 如果备份一个数据库时，没有带上 -B 参数， 在恢复数据库时，需要先创建空数据库，然后使用数据库，再使用 source 来还原。  6. 查看连接情况 查看连接情况可以告诉我们当前有哪些用户连接到我们的 MySQL，如果查出某个用户不是我们正常登陆的，很有可能我们的数据库被人入侵了。以后大家发现自己数据库比较慢时，可以用这个指令来查看数据库连接情况。  语法：          show processlist; 1 例如：   二、表的操作 1. 创建表 语法：          CREATE TABLE table_name (             field1 datatype,             field2 datatype,             field3 datatype         ) character set 字符集 collate 校验规则 engine 存储引擎; 在创建表之前需要指定数据库，即使用：use 数据库; 为该数据库创建表。  注意，数据库的数据类型我们暂时先不介绍，后续会介绍。  说明：  field 表示列名 datatype 表示列的类型 character set 字符集，如果没有指定字符集，则以所在数据库的字符集为准 collate 校验规则，如果没有指定校验规则，则以所在数据库的校验规则为准 例如我们创建一个 users 表，里面存储用户的 id、用户名、密码、生日：          create table users(             -> id int,             -> name varchar(20) comment '用户名',             -> password char(20) comment '密码',             -> birther date comment '生日'             -> ) character set utf8 engine MyISAM; 说明：不同的存储引擎，创建表的文件不一样。users 表存储引擎是 MyISAM ，在数据库目录中有三个不同的文件，我们可以进入该目录查看：cd /var/lib/mysql/d1，分别是：   其中，它们分别表示：  users.frm：表结构 users.MYD：表数据 users.MYI：表索引 而 db.opt 则是该数据库对应的字符集和检验规则。  2. 查看表 上面我们已经创建好了一张 users 表，此时我们可以查看该数据库有哪些表：show tables;   3. 查看表结构 语法：desc 表明;  例如查看 users 表的结构：   以上就是表的结构中的介绍，我们后面会详细介绍每一列的功能的。  4. 修改表 在项目实际开发中，经常修改某个表的结构，比如字段名字，字段大小，字段类型，表的字符集类型，表的存储引擎等等。我们还有需求，添加字段，删除字段等等；这时我们就需要修改表。          ALTER TABLE tablename ADD (column datatype [DEFAULT expr][,column         datatype]...);  # 添加                  ALTER TABLE tablename MODIfy (column datatype [DEFAULT expr][,column         datatype]...);  # 修改                  ALTER TABLE tablename DROP (column);  # 删除 例如：  先在 users 表添加两条记录：      mysql> insert into users values(1, 'a', 'b', '2000-01-01'),          -> (2, 'c', 'd', '2000-01-02'); 1 2  在 users 表添加一个字段，用于保存图片路径：alter table users add assets varchar(100) comment '图片路径' after birther;  插入新字段后，我们查看原表的数据，对原来表中的数据没有影响：   修改 name，将其长度改成 60： alter table users modify name varchar(60);  删除 password 列： alter table users drop password;  我们再查看表中的数据，发现 password 这一列的数据都不见了：   所以删除字段一定要小心，删除字段及其对应的列数据都没了。  修改表名为 employee： alter table users rename to employee; ，其中 to 可以省略  将 name 列修改为 xingming： alter table employee change name xingming varchar(60); ，新字段需要完整定义  5. 删除表 语法：DROP [TEMPORARY] TABLE [IF EXISTS] tbl_name [, tbl_name] ...  例如：   再次查看：  ———————————————— 版权声明：本文为CSDN博主「YoungMLet」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/YoungMLet/article/details/134977958 

问题来源】【必填】    【南海农商行】【问题简要】【必填】 ICD V300R008C25 数据库接口方式，调用“外呼结果回写接口OBS_CallResultProc”，返回报错。【问题类别】【必填】    【可选问题分类：ICD obs 】【AICC解决方案版本】【必填】    【AICC可选择版本：AICC 22.100】    【UAP可选择版本：V100R005】    【CTI可选择版本：ICD V300R008C25SPC012】【期望解决时间】【选填】尽快【问题现象描述】【必填】查看obs日志：查看dbop下面的日志其中一条的文本内容： 数据源：rdWork3,Msg Hstmt= [47514], RecvTime=10:26:37:341, SessionTime=10:26:37:341 ,Time: 2024-01-08;10:26:37:344,来源：106.0.52.222:1301(),类型：MSG_PROXY_EXECUTE_NEW,语句：OBS_CallResultProc,输入：1:;2:0101;3:oct1703756093342qfJ55;4:2;5:1234343545;6:00551;7:1;8:1;9:0;10:2024-01-08 10:25:59;11:2024-01-08 10:25:59;12:2024-01-08 10:26:37;13:1704680759-67068;,结果：,失败，描述：执行失败，错误：错误类型: SA_DBMS_API_ERROR; 错误码：1366; 错误描述: INCORRECT STRING VALUE: '\X89\X01' FOR COLUMN 'I_SUNIQUEID' AT ROW 1

 一、索引优化 1、索引是什么： 通过一些约束，快速查询到相应字段的一种数据结构  索引在sql优化中占有非常重要的地位，因为索引与查询挂钩，查询是我们最常做的一个操作。  2、索引的数据结构： Hash索引：查询快，但是不支持范围查询，只能精确定位某个数据。  B+树索引：查询较快，支持范围查询，这也是InnoDB存储引擎中默认的索引结构  B+树结构：  多路平衡树，每个节点存放key和指针，指针数量等于key数量+1   插播小知识：  B+树与B树，有什么区别，为什么不用二叉树？？？  B+树没个非叶子结点只存放指针，可以最大限度的降低树的高度，提高查询效率。  所有数据存放在叶子节点，查询稳定，而二叉树层次会更深，也会有退化为链表的风险  3、索引种类： 聚簇索引：叶子节点中主键下面挂的是每一行的数据  二级索引：叶子节点中索引值下面挂的是主键id  4、sql分析（回表查询） 现有user表，id为主键，name有唯一约束和唯一索引结构，分析下面sql语句。  -- select * from user where id = 1;  -- select * from user where name = 'zhang';  分析：  ①where 后面是id，从主键索引里面查找，找到了id为1的，再看前面select 后面是 * 主键下面包含了这些字段信息，直接返回。  ②where 后面是name，并且有唯一索引结构，从该索引查找，找到了姓名为zhang的，同样select * 也是查询所有字段，但是此时name下面只有主键id的值，他要根据id再次查询主键索引，性能低  二、定位慢查询语句 1、慢查询日志 mysql带有慢查询日志，该日志会记录超过指定时间的sql语句， 注意：  慢查询日志默认为不开启，开启之后默认指定时间为10s。  可通过修改配置文件来设置这两参数。  修改mysql的配置文件   缺点：  有些sql在规定的时间之内，但是查询花了9.9秒，并且性能很低，慢查询日志无法记录这样的sql我们也就无法优化.  2、profile详情 show profiles 查看sql语句的执行时间  show profile for query query_id; 查看指定语句的执行时间  3、explain执行计划（重点） explain执行计划：他记录了sql查询的一些详细信息 例如：查询部门和员工信息，  控制台返回这么一张表，我们重点关注这5个字段。   type：  表示访问表的方式，是性能分析中重要的一个指标。常见的取值有： ALL：全表扫描。 index：通过索引扫描。 range：通过索引范围扫描。 ref：非唯一性索引扫描。 eq_ref：唯一性索引扫描。 const：单表中最多有一个匹配行的情况。 反应查询效率 从高到底分别是NULL->system->const->eq_ref->ref->range->index->all  all性能最差，也就是它是全表扫描，没有使用索引，NULL 只有像select 'A' 这样的没有查表才会这样，所以开发中我们尽量优化到system 或者const或者ref级别。  possible_keys:  可能使用的索引，但不一定用到 key:  使用的索引 key_len:  使用索引的长度（字节为单位） Extra:  包含有关查询的额外信息，可能包括： Using index：表示查询使用了覆盖索引。 Using where：表示 MySQL 会在存储引擎层使用 WHERE 条件过滤行。 Using temporary：表示查询需要创建临时表。 Using filesort：表示 MySQL 会对结果使用文件排序。 4、查看执行频次  ———————————————— 版权声明：本文为CSDN博主「不会就选C.」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/Panci_/article/details/134918156 

问题来源】【必填】    【南海农商行】【问题简要】【必填】 ICD V300R008C25 数据库接口方式，通过“取外呼任务接口”，获取到任务数据之后。后面的步骤在obs的日志发现" 调用CTIAPI接口失败 CTIApiName:CccGetDeviceBySkillsWithVDN,VdnID=3,ServiceID=oct1702888507020s11kW,@@skillB,ErrorCode:16,ErrInfo:。"【问题类别】【必填】    【可选问题分类：ICD obs】【AICC解决方案版本】【必填】    【AICC可选择版本：AICC 22.100】    【UAP可选择版本：V100R005】    【CTI可选择版本：ICD V300R008C25SPC012】【期望解决时间】【选填】尽快【问题现象描述】【必填】obs服务获取到任务数据obs日志发现报错：其中这些技能组skillA、skillB是对应的vdn管理员配置的：192.168.0.76:3306@work3?CharacterEncodingName:utf8这个配置的日志日志文件：

 MySql查询表是否被锁 查看表被锁状态  # 查询哪些表锁了 show OPEN TABLES where In_use > 0; 查看造成死锁的sql语句  # 查询innodb引擎的运行时信息 show engine innodb status; 查询进程  # 查询所有进程 show processlist; 解锁(删除进程)  # 删除进程 kill id; 查看正在执行的事务  # 查看正在执行的事务 select * from information_schema.INNODB_TRX; 查看正在锁的事物  # 查看正在锁的事物 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS 查看等待锁的事物  # 查看等待锁的事务 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; MySql出现数据库表被锁解决方案 出现的现象 页面出现502错误，数据库CPU持续飙升，大量事务堆积未提交成功（事务一直处于阻塞阶段）  查看阻塞事务列表，发现其中有锁表现象。  排查与解决思路 1）查看数据库中是否有表被锁  show open tables where in_use > 0; 如果上述返回有结果，说明有表正在被使用，返回字段如下  | Database | Table | In_use | Name_locked | 2）查看进程（只会显示当前用户的进程，除非是root用户）  show processlist; 3）查看当前运行所有事务  SELECT * FROM information_schema.INNODB_TRX; 4）查看当前出现的所有锁  SELECT * FROM information_schema.INNODB_LOCKs; 5）查询锁等待的对应关系  SELECT * FROM information_schema.INNODB_LOCK_waits; 查看事务表 INNODB_TRX中 是否有正在锁定的事务线程  确认 ID 是否在 show processlist 的 sleep 线程中：如果在，说明这个sleep的线程事务一直没有commit 或者 rollback，而是卡住了，需要手动kill掉。  搜索的结果中，如果在事务表发现了很多任务，最好都 kill 掉。  6）清理事务指定的线程 ID  kill 1234; 原文地址 MySql中怎样查询表是否被锁_Mysql_脚本之家 (jb51.net) https://www.jb51.net/database/2934268li.htm  文章知识点与官方知识档案匹配，可进一步学习相关知识 MySQL入门技能树数据库组成表76311 人正在系统学习中  ———————————————— 版权声明：本文为CSDN博主「无聊的何宝荣」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/yukiwe7/article/details/133673777 

问题来源】【必填】    【南海农商行】【问题简要】【必填】 ICD V300R008C25 数据库接口方式，通过“取外呼任务接口”，获取到任务数据后，在“系统监控台”查看obs任务信息，发现中文乱码。【问题类别】【必填】    【可选问题分类：ICD obs 中文乱码】【AICC解决方案版本】【必填】    【AICC可选择版本：AICC 22.100】    【UAP可选择版本：V100R005】    【CTI可选择版本：ICD V300R008C25SPC012】【期望解决时间】【选填】尽快【问题现象描述】【必填】本地数据的字符集是utf8在“Web配置台”中的数据源中，配置连接字符串为：ip:3306@work3?CharacterEncodingName:UTF8获取到任务数据后，在“系统控制台”查看任务数据发现中文乱码：尝试过：1、将连接字符串为：ip:3306@work3?CharacterEncodingName:GBK        结果是存在中文乱码2、创建新的数据库，数据库字符设置为GBK，且将连接字符串为：ip:3306@work3?CharacterEncodingName:GBK       结果也是存在一样的中文乱码。所以，发帖请教老师们一下，可以检查哪里的配置来解决这个问题？

 在MySQL中，当遇到枚举字段时，选择使用varchar还是数字类型（如tinyint）是一个常见的问题。根据观察，很多人倾向于使用tinyint，而少数会选择varchar。  ENUM和SET是MySQL中的字符串数据类型，与CHAR和VARCHAR这类可以随意插入任意字符的字符串类型不同，ENUM和SET只能在指定的集合里取值。例如，当使用ENUM类型创建表时，每个枚举值都需要用单引号引起来，如：`CREATE TABLE shirts ( name VARCHAR(40), size ENUM('x-small', 'small', 'medium', 'large', 'x-large') );`。  从效率的角度来看，tinyint作为数字类型，在查询时通常会比varchar类型更快。但是，如果枚举值较多，使用tinyint可能会导致数据冗余，因为一个整数可能对应多个枚举值。相反，使用varchar可以更直观地显示枚举值，但在某些查询场景下可能不如tinyint高效。