微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦！

Mysql 5.7 Gtid内部学习(六) Mysql启动初始化Gtid模块

分类：MySQL作者：编程之家AI导航网

简书地址：
http://www.jianshu.com/p/fc836446cde0

本节也是一个重头戏，后面的故障案例也和本节有关。本节将详细介绍Gtid模块的初始化，以及什么时候读取了我们前文提及的两个Gtid持久化介质：

此外也会描述他们的读取方式。
同时分析这个步骤我也将在重点步骤分为两种情况来分别讨论：

  1. 主库开启Gtid开启binlog。
  2. 从库开启Gtid开启binlog不开启log_slave_updates参数。

因为这两种使我们通常设置的方式，下面简称主库和从库。

一、初始化Gtid 模块全局变量内存空间

首先初始化Gtid 几个Global 内存空间包括 Gtid_state\Sid_map\gtid_table_persistor
这个调用由MysqLd.cc调入gtid_server_init()。 

 if (init_server_components())
    unireg_abort(MysqLD_ABORT_EXIT);

其中init_server_components()会初始化很多模块Gtid只是其中很小的一个，Innodb就在这里初始化。

gtid_server_init()函数片段如下： 

(!(global_sid_lock= new Checkable_rwlock(
#ifdef HAVE_PSI_INTERFACE
                                             key_rwlock_global_sid_lock
#endif
                                            )) ||
     !(gtid_mode_lock= new Checkable_rwlock(
#ifdef HAVE_PSI_INTERFACE
                                            key_rwlock_gtid_mode_lock
#endif
                                           )) ||
     !(global_sid_map= new Sid_map(global_sid_lock)) || //new一个内存Sid_map内存空间出来
     !(gtid_state= new Gtid_state(global_sid_lock, global_sid_map))||//new一个内存Gtid_state内存空间出来
     !(gtid_table_persistor= new Gtid_table_persistor()));//new一个内存Gtid_table_persistor内存空间出来

二、初始化获得本数据库的server_uuid

这个初始化过程在前文提到了，无非就是通过my.cnf获得server_uuid，如果没有则重新生成，具体可以参考一下前文这里不再过多描述。 

 if (init_server_auto_options())
  {
    sql_print_error("Initialization of the server's UUID Failed because it Could"
                    " not be read from the auto.cnf file. If this is a new"
                    " server, the initialization Failed because it was not"
                    " possible to generate a new UUID.");
    unireg_abort(MysqLD_ABORT_EXIT);
  }

三、初始化Gtid_state全局结构 

 global_sid_lock->rdlock();
  int gtid_ret= gtid_state->init();//将server_uuid对应的sid(Uuid)和sidno加入到
Sid_map中。
  global_sid_lock->unlock();

  if (gtid_ret)
    unireg_abort(MysqLD_ABORT_EXIT);

其实本步骤也是完成了sidno的加入Sid_map中，有兴趣的可以参考int Gtid_state::init()函数逻辑非常简单。

四、读取MysqL.gtid_executed表

这一步开始读取我们的第一个Gtid持久化介质MysqL.gtid_executed表，其最终调用为Gtid_table_persistor::fetch_gtids(Gtid_set *gtid_set)其原理为一行一行的读取MysqL.gtid_executed表的内容加入到Gtid_state.executed_gtids中，我们来看源码： 

 // Initialize executed_gtids from MysqL.gtid_executed table.
  if (gtid_state->read_gtid_executed_from_table() == -1)
    unireg_abort(1);

Gtid_state::read_gtid_executed_from_table只是一层简单的封装如下： 

int Gtid_state::read_gtid_executed_from_table()
{
  return gtid_table_persistor->fetch_gtids(&executed_gtids);
}

接下来看看Gtid_table_persistor::fetch_gtids(Gtid_set *gtid_set)函数逻辑片段 

 if ((err= table->file->ha_rnd_init(true)))
  {
    ret= -1;
    goto end;
  }

  while(!(err= table->file->ha_rnd_next(table->record[0]))) //开始一行一行读取数据
  {
    /* Store the gtid into the gtid_set */

    /**
      @todo:
      - take only global_sid_lock->rdlock(), and take
        gtid_state->sid_lock for each iteration.
      - Add wrapper around Gtid_set::add_gno_interval and call that
        instead.
    */
    global_sid_lock->wrlock();
    if (gtid_set->add_gtid_text(encode_gtid_text(table).c_str()) !=  //此处将读取到的一行Gtid区间加入到Gtid_state.executed_gtids中。
        RETURN_STATUS_OK)
    {
      global_sid_lock->unlock();
      break;
    }
    global_sid_lock->unlock();
  }

完成本步骤过后Gtid_state.executed_gtids将设置，主库和从库的设置不同

  • 主库因为MysqL.gtid_executed只包含上一个binlog的全部Gtid所以，它不包含最新binlog的Gtid，所以在第七步还需要修正这个值。
  • 从库因为MysqL.gtid_executed会实时更新，因此它包含了全部的Gtid。

五、定义中间变量和获得指针

本步骤是一个非关键步骤但是定义了一些中间变量而且定义了4个指针来分别获得Gtid_state四个内存变量的地址，方便操作。 

 if (opt_bin_log) //如果binlog开启
  {
    /*
      Initialize GLOBAL.GTID_EXECUTED and GLOBAL.GTID_PURGED from
      gtid_executed table and binlog files during server startup.
    */
    Gtid_set *executed_gtids=
      const_cast<Gtid_set *>(gtid_state->get_executed_gtids());//获得Gtid_state.executed_gtids的指针
    Gtid_set *lost_gtids=
      const_cast<Gtid_set *>(gtid_state->get_lost_gtids());//获得gtid_state.get_lost_gtids的指针
    Gtid_set *gtids_only_in_table=
      const_cast<Gtid_set *>(gtid_state->get_gtids_only_in_table());//获得gtid_state.get_lost_gtids的指针
    Gtid_set *prevIoUs_gtids_logged=
      const_cast<Gtid_set *>(gtid_state->get_prevIoUs_gtids_logged());//获得gtid_state.prevIoUs_gtids_logged的指针

    Gtid_set purged_gtids_from_binlog(global_sid_map, global_sid_lock);//定义临时变量用于存储从binlog中扫描到已经丢弃的Gtid事物。
    Gtid_set gtids_in_binlog(global_sid_map, global_sid_lock);//定义中间变量binlog中包含的所有Gtid事物包括丢弃的。
    Gtid_set gtids_in_binlog_not_in_table(global_sid_map, global_sid_lock);//定义中间变量没有存放在表中而在binlog中存在过的Gtid事物，
//显然主库包含这样一个集合，因为主库的gtids_in_binlog>gtids_only_in_table，而从库同样也不包含这样一个集合因为从库的全部Gtid事物都在表中。

六、读取binlog文件

本步骤将会读取我们提及的第二个Gtid持久化介质binlog，其读取方式为先反向读取获得 gtids_in_binlog然后正向读取获得 purged_gtids_from_binlog，并且这里正向读取purged_gtids_from_binlog将会受到binlog_gtid_simple_recovery参数的影响。同时我们前文所描述5.7 中PrevIoUs gtid Event会在没有开启Gtid的binlog也包含这个event，将在这部体现出它的价值。 

if (MysqL_bin_log.init_gtid_sets(&gtids_in_binlog,
                                     &purged_gtids_from_binlog,
                                     opt_master_verify_checksum,
                                     true/*true=need lock*/,
                                     NULL/*trx_parser*/,
                                     NULL/*gtid_partial_trx*/,
                                     true/*is_server_starting*/))

我们发现他实际上就是调用bool MysqL_BIN_LOG::init_gtid_sets()函数我们继续看这个函数重要代码片段： 

 list<string> filename_list; //定义一个string list来存储文件名
  LOG_INFO linfo;
  int error;

  list<string>::iterator it;//定义一个list的正向迭代器
  list<string>::reverse_iterator rit;//定义一个list的反向迭代器

for (error= find_log_pos(&linfo, NULL, false/*need_lock_index=false*/); !error; //这部分实际上就是将文件名全部加入到这个list中
       error= find_next_log(&linfo, false/*need_lock_index=false*/))
  {
    DBUG_PRINT("info", ("read log filename '%s'", linfo.log_file_name));
    filename_list.push_back(string(linfo.log_file_name));
  }
  if (error != LOG_INFO_EOF)
  {
    DBUG_PRINT("error", ("Error reading %s index",
                         is_relay_log ? "relaylog" : "binlog"));
    goto end;
  }

 if (all_gtids != NULL) //数据库启动初始化的情况下all_gtids不会为NULL，但是如果是做purge binary logs命令等删除binlog log all_gtid会传入NULL
  {
    rit= filename_list.rbegin(); //反向迭代器指向list尾部
    bool can_stop_reading= false;
    reached_first_file= (rit == filename_list.rend());//如果只有一个binlog则为true
    while (!can_stop_reading && !reached_first_file) //开始反向循环扫描来获得gtids_in_binlog(all_gtids)集合
    {
      const char *filename= rit->c_str(); //获取文件名
      rit++;
      reached_first_file= (rit == filename_list.rend());//如果达到第一个文件则为true表示扫描完成
      switch (read_gtids_from_binlog(filename, all_gtids,
                                     reached_first_file ? lost_gtids : NULL,
                                     NULL/* first_gtid */,
                                     sid_map, verify_checksum, is_relay_log)) //通过函数read_gtids_from_binlog读取这个binlog文件
      {
        case ERROR:
        {
          error= 1;
          goto end;
        }
        case GOT_GTIDS:  //如果扫描本binlog有PREVIoUS GTID EVENT和GTID EVENT 则break 跳出循环且设置can_stop_reading= true
        {
          can_stop_reading= true;
          break;
        }
        case GOT_PREVIoUS_GTIDS://如果扫描本binlog只有PREVIoUS GTID EVENT 则进入逻辑判断
        {
          if (!is_relay_log)//我们只考虑binlog 不会是relaylog 那么 break 跳出循环且设置can_stop_reading= true，
                            //注意这里并不受到binlog_gtid_simple_recovery参数的影响，我们知道5.7.5过后每一个binlog都
                            //包含了PREVIoUS GTID EVENT实际上即使没有开启GTID这里也会跳出循环，则只是扫描了最后一个binlog 文件
            can_stop_reading= true;
          break;
        }
        case NO_GTIDS: //如果没有找到PREVIoUS GTID EVENT和GTID EVENT 则做如下逻辑，实际上5.7过后不可能出现这种问题，因为必然包含了PREVIoUS GTID EVENT
                       //即便是没有开启GTID，所以反向查找一定会在扫描最后一个文件后跳出循环
        {
          if (binlog_gtid_simple_recovery && is_server_starting &&
              !is_relay_log) //这里受到了binlog_gtid_simple_recovery参数的影响，但是我们知道这个分支是不会执行的。除非这个数据库是升级的并且没有开启Gtid
          {
            DBUG_ASSERT(all_gtids->is_empty());//断言all_gtids还是没有找到
            DBUG_ASSERT(lost_gtids->is_empty());//断言lost_gtids还是没有找到
            goto end;//结束扫描，从这里我们发现如果MysqL是升级而来的一定要注意这个问题，设置binlog_gtid_simple_recovery可能拿不到正确的GTID，对于升级
                     //最好使用master-slave 进行升级，可以规避这个风险。
          }
          /*FALLTHROUGH*/
        }
        case TruncATED:
        {
          break;
        }
      }
    }
//中间还有一部分处理relaylog的占时没有去研究接下来就是正向查找获得purged_gtids_from_binlog(lost_gtids)

 if (lost_gtids != NULL && !reached_first_file)//如果前面的扫描没有扫描完全部的binlog，这实际在5.7中是肯定的。
  {
   
    for (it= filename_list.begin(); it != filename_list.end(); it++)//进行正向查找
    {
      /*
        We should pass a first_gtid to read_gtids_from_binlog when
        binlog_gtid_simple_recovery is disabled, or else it will return
        right after reading the PREVIoUS_GTIDS event to avoid stall on
        reading the whole binary log.
      */
      Gtid first_gtid= {0, 0};
      const char *filename= it->c_str();//获得文件名指针
      switch (read_gtids_from_binlog(filename, NULL, lost_gtids,
                                     binlog_gtid_simple_recovery ? NULL :
                                                                   &first_gtid,
                                     sid_map, verify_checksum, is_relay_log))
      {
        case ERROR:
        {
          error= 1;
          /*FALLTHROUGH*/
        }
        case GOT_GTIDS: //如果扫描本binlog有PREVIoUS GTID EVENT和GTID EVENT 则跳出循环直达end
        {
          goto end;
        }
        case NO_GTIDS: //这里如果binlog不包含GTID EVENT和PREVIoUS GTID EVENT其处理逻辑一致
        case GOT_PREVIoUS_GTIDS:
        {
          if (binlog_gtid_simple_recovery) //这里受到了binlog_gtid_simple_recovery。如果设置为ON，实际上在5.7过后
            goto end;                      //PREVIoUS GTID EVENT是一定命中的，可以得到正确的结果，但是如果是5.6升级而来
          /*FALLTHROUGH*/                  //则binlog不包含PREVIoUS GTID EVENT则purged_gtids_from_binlog(lost_gtids)获取为空
                                           //如果在5.7中关闭了GTID，这种情况这里虽然PREVIoUS GTID EVENT命中但是任然
                                           //不会跳出循环goto end,继续下一个文件扫描。
        }                                  
        case TruncATED:
        {
          break;
        }
      }
    }

到这里我们分析了反向查找和正向查找，我们代码注释上也说明了binlog_gtid_simple_recovery作用，因为有了PREVIoUS GTID EVENT的支持，5.7.6过后这个参数默认都是设置为true，如果在Gtid关闭的情况下设置binlog_gtid_simple_recovery为flase可能需要扫描大量的binlog才会确定purged_gtids_from_binlog这个集合，这可能出现在两个地方：

  • 如这里讨论的MysqL重启的时候。
  • 如前文所讨论在purge binary logs to或者操作参数expire_logs_days设置的时间删除binlog的时候。

这里也是我后文描述的第二个案例出现的原因。

正常情况下到这里我们的gtids_in_binlog和purged_gtids_from_binlog已经获取：

  • 主库gtids_in_binlog包含了所有最新的Gtid事物(包含丢弃的)而purged_gtids_from_binlog包含了已经丢弃的Gtid事物。
  • 从库压根没有binlog因此gtids_in_binlog和purged_gtids_from_binlog为空集合。

七、对Gtid_state.executed_gtids和MysqL.gtid_executed表的修正

如第四步描述主库通过读取MysqL.gtid_executed表获得的Gtid_state.executed_gtids并不是最新的，所以整理需要修正，代码如下： 

 if (!gtids_in_binlog.is_empty() && //如果gtids_in_binlog不为空，从库为空不走这个逻辑了，这里主要是主库对Gtid_state.executed_gtids的修正
        !gtids_in_binlog.is_subset(executed_gtids)) //并且executed_gtids是gtids_in_binlog的子集
      {
      gtids_in_binlog_not_in_table.add_gtid_set(&gtids_in_binlog);
      if (!executed_gtids->is_empty())
        gtids_in_binlog_not_in_table.remove_gtid_set(executed_gtids);   //将不在表中的GTID及gtids_in_binlog-executed_gtids 加入到gtids_in_binlog_not_in_table
    if (gtid_state->save(&gtids_in_binlog_not_in_table) == -1)//这里将gtids_in_binlog_not_in_table这个Gtid集合存储到MysqL.gtid_executed表中完成修正
      {
        global_sid_lock->unlock();
        unireg_abort(MysqLD_ABORT_EXIT);
      }
      executed_gtids->add_gtid_set(&gtids_in_binlog_not_in_table);//最后在executed_gtids中加入这个gtids_in_binlog_not_in_table，这个完成executed_gtids就是最新的Gtid_set了，完成了Gtid_state.executed_gtids的修正
    }

这一步完全是主库才会触发的逻辑：

  • 主库完成这一步Gtid_state.executed_gtids和MysqL.gtid_executed表都将修正到最新的Gtid集合。
  • 从库不做这个逻辑，因为从库的Gtid_state.executed_gtids和MysqL.gtid_executed表本来就是最新的。

到这里Gtid_state.executed_gtids也就是我们的gtid_executed变量初始化已经完成MysqL.gtid_executed表已经修正。

八、初始化Gtid_state.gtids_only_in_table

由于上一步已经获得了完整的的Gtid_state.executed_gtids 集合，这里获得Gtid_state.gtids_only_in_table只需要简单的gtids_only_in_table= executed_gtids - gtids_in_binlog相减即可。 

/* gtids_only_in_table= executed_gtids - gtids_in_binlog */
    if (gtids_only_in_table->add_gtid_set(executed_gtids) !=  //这里将executed_gtids加入到gtids_only_in_table
        RETURN_STATUS_OK)
    {
      global_sid_lock->unlock();
      unireg_abort(MysqLD_ABORT_EXIT);
    }
    gtids_only_in_table->remove_gtid_set(&gtids_in_binlog); //这里将去掉gtids_in_binlog

这一步主库和从库如下：

  • 主库由于存在Gtid_state.executed_gtids是最新的同时gtids_in_binlog也是最新的所以Gtid_state. gtids_only_in_table是一个空集合。
  • 从库由于Gtid_state.executed_gtids是最新的但是gtids_in_binlog 是一个空集合，所以Gtid_state. gtids_only_in_table和Gtid_state.executed_gtids相等。

九、初始化Gtid_state.lost_gtids

这一步开始获取Gtid_state.lost_gtids也就是我们的gtid_purged变量，这里只需要简单的用Gtid_state.gtids_only_in_table + purged_gtids_from_binlog;即可，他们都已经获取 

 /*
      lost_gtids = executed_gtids -
                   (gtids_in_binlog - purged_gtids_from_binlog)
                 = gtids_only_in_table + purged_gtids_from_binlog;
    */

 if (lost_gtids->add_gtid_set(gtids_only_in_table) != RETURN_STATUS_OK || //将gtids_only_in_table这个集合加入lost_gtids
        lost_gtids->add_gtid_set(&purged_gtids_from_binlog) !=            //将purged_gtids_from_binlog加入到这个集合
        RETURN_STATUS_OK)
    {
      global_sid_lock->unlock();
      unireg_abort(MysqLD_ABORT_EXIT);
    }

这一步主库和从库如下：

  • 主库由于Gtid_state.gtids_only_in_table为空集合，而purged_gtids_from_binlog则是获取的第一个binlog PrevIoUs gtid Event的Gtid。所以正常情况下Gtid_state.lost_gtids就等于第一个binlog的binlog PrevIoUs gtid Event 的Gtid。
  • 从库由于Gtid_state.gtids_only_in_table和Gtid_state.executed_gtids相等而purged_gtids_from_binlog是空集合，所以正常情况下从库的Gtid_state.lost_gtids就等于就等于Gtid_state.executed_gtids。也就是gtid_purged变量和gtid_executed变量相等。

到这里gtid_purged变量和gtid_executed变量以及MysqL.gtid_executed表都已经初始化完成。

十、初始化Gtid_state.prevIoUs_gtids_logged

这个值没有变量能够看到，它代表是直到上一个binlog所包含的全部的binlog Gtid。 

/* Prepare prevIoUs_gtids_logged for next binlog */
    if (prevIoUs_gtids_logged->add_gtid_set(&gtids_in_binlog) !=//很明显将扫描到的gtids_in_binlog的这个集合加入即可。
        RETURN_STATUS_OK)
    {
      global_sid_lock->unlock();
      unireg_abort(MysqLD_ABORT_EXIT);
    }

很明显因为启动的时候binlog会切换所以简单的将扫描到gtids_in_binlog加入到集合即可。
这一步主库和从库如下：

  • 主库gtids_in_binlog包含全部Gtid事物。所以gtid_state.prevIoUs_gtids_logged就包含全部binlog中的Gtid事物。但是之后会做binlog切换。
  • 从库gtids_in_binlog为空，显然gtid_state.prevIoUs_gtids_logged也为空。

十一、本节小结

通过读取MysqL.gtid_executed和binlog，然后经过一系列的运算后，我们的Gtid模块初始化完成。4个内存变量和MysqL.gtid_executed都得到了初始化，总结如下：

  1. MysqL.gtid_executed表
  • 主库在第四步读取，在第七步的修正完成初始化，它包含了现有的全部的Gtid事物。
  • 从库在第四步读取，因为从库MysqL.gtid_executed本来就是最新的不需要更改。
  1. Gtid_state.executed_gtids和它对应了变量gtid_executed
  • 主库通过第四步和第七步将Gtid_state.executed_gtids初始化，它包含了全部的Gtid事物。
  • 从库通过第四步就已经全部初始化完成，它包含了现有的全部的Gtid事物。
  1. Gtid_state.gtids_only_in_table
  • 主库通过第八步进行初始化，主库Gtid_state. gtids_only_in_table是一个空集合。
  • 从库通过第八步进行初始化，从库Gtid_state. gtids_only_in_table和Gtid_state.executed_gtids相等。
  1. Gtid_state.lost_gtids它对应了变量gtid_purged。
  • 主库通过第九步进行初始化，Gtid_state.lost_gtids就是第一个binlog PrevIoUs gtid Event的Gtid。
  • 主库通过第九步进行初始化，Gtid_state.lost_gtids等于Gtid_state.executed_gtids
  1. Gtid_state.prevIoUs_gtids_logged。
  • 主库通过第十步进行初始化，gtid_state.prevIoUs_gtids_logged就包含全部binlog中的Gtid事物
  • 从库通过第十步进行初始化，gtid_state.prevIoUs_gtids_logged为空集合。

注意本节第五步包含了binlog文件的读取方法以及binlog_gtid_simple_recovery参数的作用

学习完本节至少能够学习到：

  • 1、MysqL.gtid_executed是如何以及何时读取的。
  • 2、binlog 文件中的Gtid何时读取。
  • 3、整个Gtid模块的初始化流程及细节。
  • 4、binlog_gtid_simple_recovery参数的作用。

作者微信：


Mysql 5.7 Gtid内部学习(六) Mysql启动初始化Gtid模块

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。

相关推荐

一次彻底讲清如何处理mysql 的死锁问题
MySQL 死锁 是指两个或多个事务互相等待对方持有的锁，从而导致所有事务都无法继续执行的现象。在 InnoDB 存储引擎中，死锁是通过锁机制产生的，特别是在并发较高、业务逻辑复杂的情况下，更容易发生死锁。 一、MySQL 死锁的成因 MySQL 的死锁一般发生在 行级锁 上。常见的死锁成因包括：
MySQL 通过 Next-Key Locking 技术（行锁+间隙锁）避免幻读问题
在MySQL中，InnoDB引擎通过Next-Key Locking技术来解决幻读问题。幻读是一种事务并发问题，通常出现在Repeatable Read隔离级别下的范围查询操作中。幻读的现象是，事务在查询时多次执行相同的范围查询，但由于其他事务的插入或删除操作导致结果不一致，出现“幻觉”一样的记录。
一文彻底弄懂mysql的事务日志，undo log 和 redo log
在数据库事务管理中，Undo Log 和 Redo Log 是两种关键日志，用于保障事务的 原子性 和 持久性。它们的作用是确保数据库在出现崩溃、断电、宕机等故障时，能够进行恢复操作，从而保障数据一致性和完整性。它们通常用于支持事务的 ACID 特性中的 原子性 和 持久性。下面将分别介绍 Undo
select case when与IF的用法
case when概述 sql语句中的case语句与高级语言中的switch语句类似，是标准sql的语法，适用于一个条件判断有多种值的情况下分别执行不同的操作。 case when示例 IF语句示例 if else只能用在存储过程里
mysql 从一个表中查数据，插入另一个表
其实很简单，只是为了忘记，做个记录，用的时候方便。 不管是在网站开发还是在应用程序开发中，我们经常会碰到需要将MySQL或MS SQLServer某个表的数据批量导入到另一个表的情况，甚至有时还需要指定导入字段。 本文就将以MySQL数据库为例，介绍如何通过SQL命令行将某个表的所有数据或指定字段的
cmd命令行下登陆备份导入导出msql数据
1.进入服务，找到mysql服务，在属性里找到mysql的安装路径 2.登陆 mysql&#160;-h&#160;192.168.0.11 -P 3310 -u root -p 如果是访问的本机并且端口是默认的，那么-h和-P可以不写 3.备份 接着第一步&#160;mysqldump&#160;
sql中count(*)、count(col)、count(1)区别
count(*)和count(列)根本就是不等价的，count(*)是针对于全表的，而count(列)是针对于某一列的，如果此列值为空的话，count(列)是不会统计这一行的。 也就是说count(列)会用到索引，并且会过滤掉该列为null的那行。 而count(*)是全表扫描，并且只要某一条数据有
GROUP BY 和 ORDER BY一起使用时的注意点
order by的列，必须是出现在group by子句里的列ORDER BY要在GROUP BY的后面
sql中having、group by用法及常用聚合函数
having是用在聚合函数的用法。当我们在用聚合函数的时候，一般都要用到GROUP BY 先进行分组，然后再进行聚合函数的运算。运算完后就要用到HAVING 的用法了，就是进行判断了。 注意：select 后的字段，必须要么包含在group by中，要么包含在having 后的聚合函数里。 havi
MySQL 各类日志文件介绍
日志文件 1、错误日志 ErrorLog 错误日志记录了MyQLServer运行过程中所有较为严重的警告和错误信息，以及MySQLServer每次启动和关闭的详细信息。 在默认情况下，系统记录错误日志的功能是关闭的，错误信息被输出到标准错误输出（stderr），如果要开启系统记录错误日志的功能，需要
苹果市值2025年有望达4万亿美元
pythonJavaScriptjavaHTMLreactjsC#AndroidCSSNode.jssqlrpython-3.xMysqLjQueryc++pandasFlutterangularIOSdjangolinuxswifttypescript路由器JSON路由器设置无线路由器h3c华三华三路由器设置华三路由器电脑软件教程arraysdocker软件图文教程Cvue.jslaravelspring-bootreact-native