首页 > 数据库 >MySQL GTID详解

MySQL GTID详解

时间：2024-07-31 14:56:40浏览次数：14  
标签：sec 2a09ee6e 详解 Master GTID MySQL master 11e7 gtid

MySQL在5.6版本推出了GTID复制，相比传统的复制，GTID复制对于运维更加友好，这个事物是谁产生，产生多少事物，非常直接的标识出来。

今天将讨论一下 关于从库show slave status 中的Retrieved_Gtid_Set 和 Executed_Gtid_Set.

Retrieved_Gtid_Set : 从库已经接收到主库的事务编号

Executed_Gtid_Set : 从库自身已经执行的事务编号

下面将解释这两列的含义：

首先看看master和slave的server-uuid

Master:

[root@localhost][db1]> show variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value |
+---------------+--------------------------------------+
| server_uuid | 2a09ee6e-645d-11e7-a96c-000c2953a1cb |
+---------------+--------------------------------------+
1 row in set (0.00 sec)
Slave

[root@localhost][(none)]> show variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value |
+---------------+--------------------------------------+
| server_uuid | 8ce853fc-6f8a-11e7-8940-000c29e3f5ab |
+---------------+--------------------------------------+
1 row in set (0.01 sec)
其中主库的server-id是10,从库的server-id是20.

搭建好主从以后，如果没有数据写入，那么show slave status是下面这样的:

Replicate_Ignore_Server_Ids:
Master_Server_Id: 10
Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
如果在主库创建表，并且写入2条数据，是下面这样的:

[root@localhost][db1]> create table t2 ( id int);
Query OK, 0 rows affected (0.07 sec)

[root@localhost][db1]> insert into t2 select 1;
Query OK, 1 row affected (0.07 sec)
Records: 1 Duplicates: 0 Warnings: 0

[root@localhost][db1]> insert into t2 select 2;
Query OK, 1 row affected (0.02 sec)
Records: 1 Duplicates: 0 Warnings: 0
这里auto_commit=1,可以看到创建表加插入2条数据，一共执行了3个事务.

从库：show slave status\G

Replicate_Ignore_Server_Ids:
Master_Server_Id: 10
Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
Auto_Position: 1
主库：show master status

+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000001 | 912 | | | 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)
其中主库的 Executed_Gtid_Set为：2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3

看到从库的Retrieved_Gtid_Set为: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3

              Executed_Gtid_Set为： 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3

也就是说主库产生了3个事务，从库接收到了主库的3个事务，且都已全部执行。

其中 2a09ee6e-645d-11e7-a96c-000c2953a1cb 是主库的server-uuid. 可以从从库解析binlog看出:

# at 154
#170823  0:38:38 server id 10  end_log_pos 219 CRC32 0x6268641f         GTID    last_committed=0        sequence_number=1
SET @@SESSION.GTID_NEXT= '2a09ee6e-645d-11e7-a96c-000c2953a1cb:1'/*!*/;
# at 219
#170823  0:38:38 server id 10  end_log_pos 316 CRC32 0x6c837618         Query   thread_id=103   exec_time=0     error_code=0
use `db1`/*!*/;
SET TIMESTAMP=1503419918/*!*/;
SET @@session.pseudo_thread_id=103/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
create table t2 ( id int)
/*!*/;

可以看见server-id为10，gtid-next为2a09ee6e-645d-11e7-a96c-000c2953a1cb:1，执行了建表，剩下的

2a09ee6e-645d-11e7-a96c-000c2953a1cb:2 与 2a09ee6e-645d-11e7-a96c-000c2953a1cb:3 执行的查询我没有写出来。

这里也体现了文章开始提到的：这个事物由谁产生，产生多少事物，非常直接的标识了出来。

那么对于文章开头那个诡异的gtid是怎么出来的呢？先说说已经执行的事务：

Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1

这里的2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33好理解，就是已经执行主库的1-33的事务，那么8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1呢?其实也简单，有两种情况：

NO.1 从库有数据写入（即从库插入数据）
[root@localhost][db1]> insert into t2 select 1;
Query OK, 1 row affected (0.03 sec)
Records: 1 Duplicates: 0 Warnings: 0
show slave status\G;

Replicate_Ignore_Server_Ids:
Master_Server_Id: 10
Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
Auto_Position: 1
Replicate_Rewrite_DB:
可以看到已经执行的事务有来自主库的2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,也有从库自己写入的数据：8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1。我们可以解析binlog看看

mysqlbinlog -vv mysql-bin.000001 --include-gtids='8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1'

# at 896
#170823  0:59:19 server id 20  end_log_pos 961 CRC32 0x0492528a         GTID    last_committed=3        sequence_number=4
SET @@SESSION.GTID_NEXT= '8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1'/*!*/;
# at 961
#170823  0:59:19 server id 20  end_log_pos 1032 CRC32 0xbf545cca        Query   thread_id=25    exec_time=0     error_code=0
SET TIMESTAMP=1503421159/*!*/;
SET @@session.pseudo_thread_id=25/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 1032
#170823  0:59:19 server id 20  end_log_pos 1079 CRC32 0x2f2de3ec        Rows_query
# insert into t2 select 1
# at 1079
#170823  0:59:19 server id 20  end_log_pos 1123 CRC32 0x18fe1c5c        Table_map: `db1`.`t2` mapped to number 109
# at 1123
#170823  0:59:19 server id 20  end_log_pos 1163 CRC32 0x163a708e        Write_rows: table id 109 flags: STMT_END_F

BINLOG '
52KcWR0UAAAALwAAADcEAACAABdpbnNlcnQgaW50byB0MiBzZWxlY3QgMezjLS8=
52KcWRMUAAAALAAAAGMEAAAAAG0AAAAAAAEAA2RiMQACdDIAAQMAAVwc/hg=
52KcWR4UAAAAKAAAAIsEAAAAAG0AAAAAAAEAAgAB//4BAAAAjnA6Fg==
'/*!*/;
### INSERT INTO `db1`.`t2`
### SET
###   @1=1 /* INT meta=0 nullable=1 is_null=0 */
# at 1163
#170823  0:59:19 server id 20  end_log_pos 1194 CRC32 0xe3347ac1        Xid = 68
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;

从binlog中可以清楚看到是从库进行了写入。

NO.2 主从切换(这里使用的是MHA切换主从)
Master_Server_Id: 20
Master_UUID: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
Auto_Position: 1
可以看到主从切换以后主库的server-id是20。这里的意思是接收到主库8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1,并已经执行了这个事物，这个事物其实就是之前从库写入的那条数据。对于2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3就是之前主库执行的3个事务，如果此时在主库再插入一条数据，那么变化如下：

Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-2
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-2

下面说说GTID不连续问题，类似 2a09ee6e-645d-11e7-a96c-000c2953a1cb:37-45 ，这个是由于binlog被清理后导致的，我们可以测试一下，然后查看gtid_purge变量。

binlog不可能永远驻留在服务上，需要定期进行清理(通过expire_logs_days可以控制定期清理间隔)，否则迟早它会把磁盘用尽。gtid_purged用于记录已经被清除了的binlog事务集合，它是gtid_executed的子集。只有gtid_executed为空时才能手动设置该变量，此时会同时更新gtid_executed为和gtid_purged相同的值。gtid_executed为空意味着要么之前没有启动过基于GTID的复制，要么执行过RESET MASTER。执行RESET MASTER时同样也会把gtid_purged置空，即始终保持gtid_purged是gtid_executed的子集。

[root@localhost][db1]> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 3530 |
+------------------+-----------+
1 row in set (0.00 sec)

[root@localhost][db1]> flush logs;
Query OK, 0 rows affected (0.05 sec)

[root@localhost][db1]> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 3577 |
| mysql-bin.000002 | 234 |
+------------------+-----------+
2 rows in set (0.00 sec)

[root@localhost][db1]> PURGE BINARY LOGS TO 'mysql-bin.000002';
Query OK, 0 rows affected (0.01 sec)

[root@localhost][db1]> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000002 | 234 |
+------------------+-----------+
1 row in set (0.00 sec)
然后只要从库有重新启动，才会读取。MySQL服务器启动时，通过读binlog文件，初始化gtid_executed和gtid_purged,使它们的值能和上次MySQL运行时一致。

gtid_executed 本机被执行并写入日志的gtid
gtid_purged 该变量中记录的是本机上已经执行过，但是已经被purge binary logs to命令清理的gtid_set

没启动前：

Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9
重启并插入数据：

        Master_Server_Id: 20
              Master_UUID: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab
         Master_Info_File: mysql.slave_master_info
                SQL_Delay: 0
      SQL_Remaining_Delay: NULL
  Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
       Master_Retry_Count: 86400
              Master_Bind: 
  Last_IO_Error_Timestamp: 
 Last_SQL_Error_Timestamp: 
           Master_SSL_Crl: 
       Master_SSL_Crlpath: 
       Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:10
        Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,

8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-10
Auto_Position: 1
[root@localhost][(none)]> show variables like 'gtid_purged';
+---------------+------------------------------------------------------------------------------------+
| Variable_name | Value |
+---------------+------------------------------------------------------------------------------------+
| gtid_purged | 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9 |
+---------------+------------------------------------------------------------------------------------+
1 row in set (0.01 sec)
可以看到 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3 与 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9 都在mysql-bin.000001里，已经被清除了。

下面的两个实验，将会告诉我们如果主日志被清除，但从还没获得这些日志，该怎么处理：
实验一：如果slave所需要事务对应的GTID在master上已经被purge了
根据show global variables like '%gtid%'的命令结果我们可以看到，和GTID相关的变量中有一个gtid_purged。从字面意思以及 官方文档可以知道该变量中记录的是本机上已经执行过，但是已经被purge binary logs to命令清理的gtid_set。
本节中我们就要试验下，如果master上把某些slave还没有fetch到的gtid event purge后会有什么样的结果。

以下指令在master上执行

master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+----------------------------------------+
| Variable_name | Value |
+---------------------------------+----------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+----------------------------------------+
7 rows in set (0.01 sec)

master [localhost] {msandbox} (test) > flush logs;create table gtid_test2 (ID int) engine=innodb;
Query OK, 0 rows affected (0.04 sec)

Query OK, 0 rows affected (0.02 sec)

master [localhost] {msandbox} (test) > flush logs;create table gtid_test3 (ID int) engine=innodb;
Query OK, 0 rows affected (0.04 sec)

Query OK, 0 rows affected (0.04 sec)

master [localhost] {msandbox} (test) > show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000005 | 359 | | | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)

master [localhost] {msandbox} (test) > purge binary logs to 'mysql-bin.000004';
Query OK, 0 rows affected (0.03 sec)

master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)
在slave2上重新做一次主从，以下命令在slave2上执行

slave2 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)

slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)

slave2 [localhost] {msandbox} ((none)) > show slave status\G
*************************** 1. row ***************************
......
Slave_IO_Running: No
Slave_SQL_Running: Yes
......
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 0
Relay_Log_Space: 151
......
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Last_SQL_Errno: 0
Last_SQL_Error:
......
Auto_Position: 1
1 row in set (0.00 sec)

实验二：忽略purged的部分，强行同步
那么实际生产应用当中，偶尔会遇到这样的情况：某个slave从备份恢复后（或者load data infile）后，DBA可以人为保证该slave数据和master一致；或者即使不一致，这些差异也不会导致今后的主从异常（例如：所有master上只有insert没有update）。这样的前提下，我们又想使slave通过replication从master进行数据复制。此时我们就需要跳过master已经被purge的部分，那么实际该如何操作呢？
我们还是以实验一的情况为例：

先确认master上已经purge的部分。从下面的命令结果可以知道master上已经缺失24024e52-bd95-11e4-9c6d-926853670d0b:1这一条事务的相关日志

master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)
在slave上通过set global gtid_purged='xxxx'的方式，跳过已经purge的部分

slave2 [localhost] {msandbox} ((none)) > stop slave;
Query OK, 0 rows affected (0.04 sec)

slave2 [localhost] {msandbox} ((none)) > set global gtid_purged = '24024e52-bd95-11e4-9c6d-926853670d0b:1';
Query OK, 0 rows affected (0.05 sec)

slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)

slave2 [localhost] {msandbox} ((none)) > show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
......
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 359
Relay_Log_File: mysql_sandbox21290-relay-bin.000004
Relay_Log_Pos: 569
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
......
Exec_Master_Log_Pos: 359
Relay_Log_Space: 873
......
Master_Server_Id: 1
Master_UUID: 24024e52-bd95-11e4-9c6d-926853670d0b
Master_Info_File: /data/mysql/rsandbox_mysql-5_6_23/node2/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
......
Retrieved_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:2-3
Executed_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:1-3
Auto_Position: 1
1 row in set (0.00 sec)
可以看到此时slave已经可以正常同步，并补齐了24024e52-bd95-11e4-9c6d-926853670d0b:2-3范围的binlog日志。

转载来自原文作者地址：https://blog.csdn.net/woailyoo0000/article/details/88981380

标签：sec,2a09ee6e,详解,Master,GTID,MySQL,master,11e7,gtid
From： https://www.cnblogs.com/hgboy/p/18334619

相关文章

  • Stable Diffusion 使用详解（4）---- 制作情景文本
    目录背景制作流程绘制底图书写提示词选底模常规参数设置controlNet处理CandycontrolNet设置DepthcontrolNet设置输出效果改进适当修改提示词适当修改controlNet适当修改底模背景制作情景文本，将文本较好的融入背景图片。首先要符合设计的场景，其次要凸显......
  • 并发编程AtomicBoolean详解
    AtomicBoolean是Java中的一种原子变量类，提供了对布尔值进行原子操作的能力。它是java.util.concurrent.atomic包的一部分，使用了CAS（Compare-And-Swap）机制来实现无锁的并发控制。AtomicBoolean常用于需要以线程安全的方式对布尔值进行读写操作的场景。以下是AtomicBoo......
  • 继电器模块详解
    继电器，一种常见的电控制装置，其应用几乎无处不在。在家庭生活，继电器被广泛应用于照明系统、电视机、空调等电器设备的控制；在工业领域，它们用于控制电机、泵站、生产线等高功率设备的运行；继电器还在通信网络、交通系统以及医疗设备中发挥着重要作用。不仅如此，继电器也是学习其他电子......
  • pip安装mysqlclient报错
    pip安装mysqlclient报错报错信息Exception:Cannotfindvalidpkg-configname.SpecifyMYSQLCLIENT_CFLAGSandMYSQLCLIENT_LDFLAGSenvvarsmanually这个问题通常是由于缺少mysqlclient的开发包或者相关的环境变量导致的。要解决这个问题，你可以尝试以下几个步骤......
  • MySQL入门学习-设计优化.范式设计
        以下是关于MySQL入门学习中设计优化和范式设计的一些基本信息：一、设计优化：1.索引优化：  -选择合适的列创建索引，通常在经常用于查询、连接、排序的列上创建索引。  -避免在过多的列上创建索引，以免影响插入、更新和删除操作的性能。  -对于大型......
  • MySQL入门学习-设计优化.生成列
        在MySQL中，生成列（GeneratedColumn）是一种特殊的列类型，它的值是根据其他列的值或表达式计算得到的。生成列可以分为两种类型：存储生成列（StoredGeneratedColumn）和虚拟生成列（VirtualGeneratedColumn）。一、特点和使用方法：1.存储生成列：  -特点：    ......
  • 神经网络之卷积篇：详解计算机视觉（Computer vision）
    详解计算机视觉计算机视觉是一个飞速发展的一个领域，这多亏了深度学习。深度学习与计算机视觉可以帮助汽车，查明周围的行人和汽车，并帮助汽车避开它们。还使得人脸识别技术变得更加效率和精准，即将能够体验到或早已体验过仅仅通过刷脸就能解锁手机或者门锁。当解锁了手机，猜手机上一定......
  • PMSM电机方程详解
    一.dq轴下的电机方程1.电机方程分类做PMSM驱动，大家一定知道两个坐标系：αβ坐标系和dq坐标系。αβ坐标系，基于电机定子而言，所以又称定子坐标系或者静态坐标系。dq坐标系，基于电机转子而言，所以又称转子坐标系或者旋转坐标系。于是，在这两个坐标系下，就分别对应着各自的电机方程......
  • mysql数据类型
    002-MySQL数据类型 ==========================================数据类型 ==========================================1、数字类型：  整数类型      字节     范围（有符号）     范围（unsigned）     用途  TINYINT     ......
  • MySQL正则表达式
    004-正则表达式MySQL利用REGEXP命令提供给用户扩展的正则表达式功能，熟悉掌握REGEXP的功能可以使模式匹配工作事半功倍。表达式  说明^   字符串开始处进行匹配（以“后面字符串”开始匹配字符）$   字符串结尾处进行匹配（以“前面字符串”结尾匹配字符）.   ......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99