热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

MySQL8.0DDL原子性特性及实现原理

1.DDL原子性概述8.0之前并没有统一的数据字典dd,server层和引擎层各有一套元数据,sever层的元数据包括(.frm,.opt,.par,.trg等),用于存储表定义,分区表定义,触发器定义等信息;innodb层也有自己一套元数据,包括表信息,索引信息

1. DDL原子性概述

8.0之前并没有统一的数据字典dd,server层和引擎层各有一套元数据,sever层的元数据包括(.frm,.opt,.par,.trg等),用于存储表定义,分区表定义,触发器定义等信息;innodb层也有自己一套元数据,包括表信息,索引信息等,这两套元数据并没有机制保证一致性,这就导致了在异常情况下可能存在元数据不一致问题,一种典型场景下,删表操作,sever层的frm已经成功删除了,但引擎层数据字典并没有更新,导致再建重名表失败的问题。同样的,比如drop table t1,t2;可能出现只删除了t1,而t2仍然存在等问题。

8.0的一个重要工作是将数据字典统一,独立了DD(数据字典)模块,废弃了server层的元数据,将innodb的元数据抽象出一条DD接口供server层和innnodb层公用。在DD的基础上,引入了DDL的原子性特性,确保DDL操作要么全做,要么全不做的能力。实现这一套逻辑的关键点在于将ddl涉及到的修改,包括dd数据字典修改,引擎层的修改(创建文件,初始化tablespace,创建btree等)和写binlog作为一个“事务”,利用事务的原子性特点来保证ddl操作的原子性。

2.DDL原子性实现原理

实现原子性的关键在于确保dd数据字典修改,引擎层的修改和写binlog是一个事务。MySQL已有的XA事务机制能有效保证DML事务和binlog的一致性。而ddl数据字典也是通过innodb引擎存储,因此做到dd数据字典修改和binlog一致是容易的;那么还需要解决的一个问题是,dd数据字典和引擎层修改的一致性,引擎层的修改并不都是记redo的,比如创建文件,rename文件名,或者清理cache等,无法简单地通过XA机制解决问题,因此8.0还引入了一套DDL_LOG机制。具体而言,就是将不记redo的一些操作,通过记日志的方式写入到ddl_log表中,而这个表是innodb引擎表,通过保证ddl_log数据与dd数据字典修改达成一致,而最终解决dd数据字典修改,引擎层的修改和写binlog一致性问题。

3.DD引入前后对比

​

​​

4.DDL操作实现逻辑

引入ddl_log表后,ddl操作在原有的基础上有一些变化,主要有两点,一点是在执行ddl的过程中,会记录ddl操作到ddl_log表中;另一点是新增了一个post_ddl阶段,ddl事务提交后,做一些ddl的收尾动作,比如drop-table,真正的删除物理文件是在post-ddl阶段做的。post-ddl做的事情主要就是,读取ddl-log内容,进行回放执行。ddl操作类型如下:

enum class Log_Type : uint32_t {
/** Smallest log type */
SMALLEST_LOG = 1,
/** Drop an index tree */
FREE_TREE_LOG = 1,
/** Delete a file */
DELETE_SPACE_LOG,
/** Rename a file */
RENAME_SPACE_LOG,
/** Drop the entry in innodb_dynamic_metadata */
DROP_LOG,
/** Rename table in dict cache. */
RENAME_TABLE_LOG,
/** Remove a table from dict cache */
REMOVE_CACHE_LOG,
/** Alter Encrypt a tablespace */
ALTER_ENCRYPT_TABLESPACE_LOG,
/** Biggest log type */
BIGGEST_LOG = ALTER_ENCRYPT_TABLESPACE_LOG
};

通过innodb_print_ddl_logs开关,可以看到ddl过程中写入到innodb_ddl_log表中的内容。下面会以几个典型的ddl操作产生的ddl_log来说明如何保证ddl的原子性。

4.1 create table

语句:create table dd_tt(id int primary key, c1 int);

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=352, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log delete : 352
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=353, thread_id=23, table_id=1128, new_file_path=mysql/dd_tt]
[InnoDB] DDL log delete : 353
[InnoDB] DDL log insert : [DDL record: FREE, id=354, thread_id=23, space_id=71, index_id=231, page_no=4]
[InnoDB] DDL log delete : 354
[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log post ddl : end for thread id : 23 

说明:

1.所有insert操作都是一个单独的事务,对应的逆向delete操作是整个ddl事务的一部分。

2.insert操作记录的是文件操作的逆向操作,比如建table_space,逆向操作就是delete_space_log。

3.如果ddl事务最终成功,那么所有逆向delete操作也最终生效,ddl_log日志被正常清理;如果ddl事务执行过程中失败(比如实例crash),那么delete操作回滚,ddl_log表中残留3条insert_log,recover时,replay这些ddl_log,即可以清理ddl过程中产生的垃圾。

4.crash-recovery时,若binlog已经落盘,则对应的ddl事务处于prepare状态,那么最终事务要提交,ddl_log被清理干净;若binlog没有落盘,则ddl事务需要回滚,ddl_log表中残留3条记录,在故障恢复结束后,需要replay这些记录,实际上就是建文件,创建btree等逆向操作,确保回滚后是干净的。

4.2 drop table

语句:drop table dd_tt;

[InnoDB] DDL log insert : [DDL record: DROP, id=355, thread_id=23, table_id=1128]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=356, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=356, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log replay : [DDL record: DROP, id=355, thread_id=23, table_id=1128]
[InnoDB] DDL log post ddl : end for thread id : 23

说明:对于drop操作而言,执行过程中只是操作ddl_log,并不做真正的drop物理表操作。在post-ddl阶段,会读取ddl_log表中的记录并replay,做真正的删除动作。如果执行过程中crash了,那么整个ddl事务会回滚,这其中也包含ddl_log中的内容也会回滚,那么整个drop操作就相当于没发生一样。

4.3 add index

语句:alter table dd_tt add index idx_c1(c1);

[InnoDB] DDL log insert : [DDL record: FREE, id=360, thread_id=23, space_id=72, index_id=233, page_no=5]   
[InnoDB] DDL log delete : 360
[InnoDB] DDL log post ddl : begin for thread id : 23                
[InnoDB] DDL log post ddl : end for thread id : 23

说明: 建索引与建表类似,insert操作部分是一个事务,单独提交,配套会记录一个delete操作,这个操作是整个ddl事务的一部分,事务如果最终提交,那么ddl-log内容被删除;如果事务最终回滚,那么ddl-log中会残留一条FREE-log,通过replay则可以清理建好的索引,达到回滚的效果。

4.4 drop index

语句:alter table dd_tt drop index idx_c1;

[InnoDB] DDL log insert : [DDL record: FREE, id=361, thread_id=23, space_id=72, index_id=233, page_no=5]
[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log replay : [DDL record: FREE, id=361, thread_id=23, space_id=72, index_id=233, page_no=5]
[InnoDB] DDL log post ddl : end for thread id : 23 

说明:

与drop table类似,执行过程中只记录日志,在post-ddl阶段才进行真正的删除操作。

4.5 add column

语句:alter table dd_tt add column c2 int;

[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log post ddl : end for thread id : 23

说明:

8.0加列是instant-ddl,只修改元数据,与dml事务类似,不依赖ddl-log保证原子性。

4.6 drop column

语句:alter table dd_tt drop column c2;

语句分解:

1.prepare阶段:

create table #sql-ib1129-2815969725;

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=362, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1129-2815969725.ibd] 
[InnoDB] DDL log delete : 362
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=363, thread_id=23, table_id=1130, new_file_path=mysql/#sql-ib1129-2815969725]  
[InnoDB] DDL log delete : 363
[InnoDB] DDL log insert : [DDL record: FREE, id=364, thread_id=23, space_id=73, index_id=234, page_no=4]         
[InnoDB] DDL log delete : 364

2.peform阶段:nothing about ddl-log

3.commit阶段:

3.1 alter table dd_tt rename to #sql-ib1130-2815969726;

[InnoDB] DDL log insert : [DDL record: DROP, id=365, thread_id=23, table_id=1129]     
[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=366, thread_id=23, space_id=72, old_file_path=./mysql/#sql-ib1130-2815969726.ibd, new_file_path=./mysql/dd_tt.ibd] [InnoDB] DDL log delete : 366 [InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=367, thread_id=23, table_id=1129, old_file_path=mysql/#sql-ib1130-2815969726, new_file_path=mysql/dd_tt] [InnoDB] DDL log delete : 367

逆向操作:alter table mysql/#sql-ib1130-2815969726 rename to dd_tt;

3.2 alter table #sql-ib1129-2815969725 rename to dd_tt;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL log delete : 368
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL log delete : 369

逆向操作:alter table dd_tt rename to mysql/#sql-ib1129-2815969725;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL log delete : 368
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL log delete : 369

仅仅记录操作,在post-ddl阶段才做清理。

post-ddl阶段:

drop table #sql-ib1130-2815969726;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL log delete : 368
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL log delete : 369

说明:drop column是copy类型的ddl,基本逻辑是新建一张临时表,拷贝数据,最后再进行一次rename操作。主要包括4个阶段:

1.prepare阶段:建临时表的过程与建表过程的ddl-log操作类似,insert-log作为单独事务直接提交,delete-log是整个事务的一部分。

这个阶段如果出现异常,ddl-log表中残留了逆操作记录,crash-recovery时,可以在replay实现清理。

2.peform阶段: 拷贝数据结束,实现online-ddl逻辑。

3.拷贝数据结束后,需要进行rename交换表名操作。

1)DROP,删除临时表

2)RENAME SPACE/TABLE 将./mysql/#sql-ib1130-2815969726.ibd 重命名为dd_tt.idb

3)REANAME SPACE/TABLE 将dd_tt.idb重名为/#sql-ib1129-2815969725.idb

4)记录删除旧表sql-ib1130-2815969726.ibd操作,post-ddl阶段做真正的删除。

如果这个阶段出现异常,同样的insert-log单独一个事务,delete作为整个事务的一部分,insert-log会残留在ddl-log表中,通过replay可以做清理,还原dd_tt的数据,并清理临时表#sql-ib1130-2815969726.ibd。

4.post-ddl阶段:

1).物理删除旧文件./mysql/#sql-ib1130-2815969726.ibd

2).清理mysql.innodb_dynamic_metadata中相关信息。

需要注意的是,由于ddl-log表存放的内容实际上逆向操作,所以搜集ddl-log时,实际上是逆序搜集回放的。

4.7 truncate table

语句:truncate table dd_tt;

语句分解:

1.rename dd_tt to #sql-ib1130-2815969727;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=372, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd, new_file_path=./mysql/dd_tt.ibd
[InnoDB] DDL log delete : 372

2.drop table #sql-ib1130-2815969727;

[InnoDB] DDL log insert : [DDL record: DROP, id=373, thread_id=23, table_id=1130]     
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=374, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd]

3.create table dd_tt;

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=375, thread_id=23, space_id=74, old_file_path=./mysql/dd_tt.ibd]     
[InnoDB] DDL log delete : 375
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=376, thread_id=23, table_id=1131, new_file_path=mysql/dd_tt]      
[InnoDB] DDL log delete : 376
[InnoDB] DDL log insert : [DDL record: FREE, id=377, thread_id=23, space_id=74, index_id=235, page_no=4]         
[InnoDB] DDL log delete : 377
[InnoDB] DDL log post ddl : begin for thread id : 23                      
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=374, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd] 
[InnoDB] DDL log replay : [DDL record: DROP, id=373, thread_id=23, table_id=1130]    

[InnoDB] DDL log post ddl : end for thread id : 23

说明:

1.将dd_tt重命名为sql-ib1130-2815969727

2.标记sql-ib1130-2815969727表删除,post-ddl阶段才真正删除

3.新建表dd_tt,同样的insert操作是作为单独事务提交,delete操作是整个事务的一部分,如果回滚,最终残留了insert操作,通过replay动作清理。

5.DDL操作代码堆栈

5.1 create-table

Sql_cmd_create_table::execute
-->mysql_create_table
 -->mysql_create_table_no_lock
  -->create_table_impl
  -->rea_create_base_table
   -->ha_create_table
    -->ha_create
     -->ha_innobase::create
     -->innobase_basic_ddl::create_impl
      -->create_table_info_t::create_table
      {
       ......
      }
 -->trans_commit_implicit
  -->ha_commit_trans
  -->MYSQL_BIN_LOG::prepare
   -->ha_prepare_low //所有事务引擎prepare
    {
    binlog_prepare
    innobase_xa_prepare
    }
  -->MYSQL_BIN_LOG::commit
   -->MYSQL_BIN_LOG::ordered_commit
    -->MYSQL_BIN_LOG::process_flush_stage_queue
     -->MYSQL_BIN_LOG::flush_thread_caches
     -->binlog_cache_mngr::flush
      -->binlog_cache_data::flush
       -->MYSQL_BIN_LOG::write_gtid
        -->Log_event::write
        -->MYSQL_BIN_LOG::Binlog_ofile::write //写binlog-gtid
       -->MYSQL_BIN_LOG::write_cache
        --> MYSQL_BIN_LOG::do_write_cache
         -->Binlog_cache_storage::copy_to
         -->stream_copy
          -->Binlog_event_writer::write
           -->MYSQL_BIN_LOG::Binlog_ofile::write //写binlog-ddl语句
    -->MYSQL_BIN_LOG::sync_binlog_file
    -->MYSQL_BIN_LOG::process_commit_stage_queue
     -->ha_commit_low
     {
      binlog_commit
      innobase_commit
      -->trx_commit_for_mysql
       -->trx_commit
        -->trx_commit_low
         -->trx_commit_in_memory
         -->trx_undo_insert_cleanup
     }
 -->innobase_post_ddl(ht->post_ddl(thd))
  -->Log_DDL::post_ddl
  -->replay_by_thread_id


-->create_table_info_t::create_table
 -->create_table_def
  -->dict_mem_table_create //构造innodb内存是字典内存对象
  -->row_create_table_for_mysql
  -->dict_build_table_def
   -->dict_build_tablespace_for_table
    -->新建xxx.idb文件
    -->Log_DDL::write_delete_space_log
    {
     -->Log_DDL::insert_delete_space_log
     -->trx_start_internal //内部开启事务,单独提交。
     -->构造DDL_Record(DELETE_SPACE_LOG)
     -->DDL_Log_Table::insert(写入物理B-Tree)
     -->Log_DDL:delete_by_id //删除ddl_log操作,作为ddl事务的一部分。
    }
    -->fil_ibd_create
    -->初始化segment,extent,page
  -->Log_DDL::write_remove_cache_log
  -->Log_DDL::insert_remove_cache_log
  -->Log_DDL::delete_by_id
 -->create_index(主表,二级索引)
  -->dict_create_index_tree_in_mem
  -->btr_create
  -->Log_DDL::write_free_tree_log
   -->Log_DDL::insert_free_tree_log
   -->Log_DDL:delete_by_id
crash-recovery -->ha_post_recover -->post_recover_handlerton -->innobase_post_recover -->Log_DDL::recover -->Log_DDL::replay_all -->Log_DDL::replay { replay_delete_space_log replay_remove_cache_log replay_free_tree_log ...... } -->delete_by_ids -->DDL_Log_Table::remove

5.2 drop table

mysql_rm_table
 -->mysql_rm_table_no_locks
  -->drop_base_table
   -->ha_delete_table
    -—>handler::ha_delete_table
     -->ha_innobase::delete_table
     -->innobase_basic_ddl::delete_impl
      -->row_drop_table_for_mysql
       -->Log_DDL::write_drop_log  // 记录删innodb_dynamic_metadata日志
       -—>Log_DDL::write_delete_space_log  // 记录删ibd日志
   -->dd::drop_table
    -->dd::cache::Dictionary_client::drop
     -->dd::cache::Storage_adapter::drop
      -->dd::sdi::drop
  -->innobase_post_ddl
   -->Log_DDL::post_ddl
    -->Log_DDL::replay_by_thread_id
     -->Log_DDL::replay
      —>Log_DDL::replay_delete_space_log // post-ddl 真正删除innodb_dynamic_metadata
      —>Log_DDL::replay_drop_log   // post-ddl 真正删除ibd
     -->delete_by_ids
      -->DDL_Log_Table::remove

drop table时,只记录删除动作日志,这些日志作为事务的整体的一部分,如果最终事务提交,那么post_ddl阶段会读取日志真正删除;如果事务回滚,那么ddl_log也会作为事务的一部分而回滚。

参考文档

https://dev.mysql.com/worklog/task/?id=9045

https://dev.mysql.com/worklog/task/?id=9173

https://dev.mysql.com/worklog/task/?id=9175

https://dev.mysql.com/worklog/task/?id=9525

https://dev.mysql.com/worklog/task/?id=9536

总结

以上所述是小编给大家介绍的MySQL8.0 DDL原子性特性及实现原理,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对网站的支持!


推荐阅读
  • eclipse学习(第三章:ssh中的Hibernate)——11.Hibernate的缓存(2级缓存,get和load)
    本文介绍了eclipse学习中的第三章内容,主要讲解了ssh中的Hibernate的缓存,包括2级缓存和get方法、load方法的区别。文章还涉及了项目实践和相关知识点的讲解。 ... [详细]
  • Linux如何安装Mongodb的详细步骤和注意事项
    本文介绍了Linux如何安装Mongodb的详细步骤和注意事项,同时介绍了Mongodb的特点和优势。Mongodb是一个开源的数据库,适用于各种规模的企业和各类应用程序。它具有灵活的数据模式和高性能的数据读写操作,能够提高企业的敏捷性和可扩展性。文章还提供了Mongodb的下载安装包地址。 ... [详细]
  • Python SQLAlchemy库的使用方法详解
    本文详细介绍了Python中使用SQLAlchemy库的方法。首先对SQLAlchemy进行了简介,包括其定义、适用的数据库类型等。然后讨论了SQLAlchemy提供的两种主要使用模式,即SQL表达式语言和ORM。针对不同的需求,给出了选择哪种模式的建议。最后,介绍了连接数据库的方法,包括创建SQLAlchemy引擎和执行SQL语句的接口。 ... [详细]
  • 本文主要复习了数据库的一些知识点,包括环境变量设置、表之间的引用关系等。同时介绍了一些常用的数据库命令及其使用方法,如创建数据库、查看已存在的数据库、切换数据库、创建表等操作。通过本文的学习,可以加深对数据库的理解和应用能力。 ... [详细]
  • 在Oracle11g以前版本中的的DataGuard物理备用数据库,可以以只读的方式打开数据库,但此时MediaRecovery利用日志进行数据同步的过 ... [详细]
  • 本文介绍了一种轻巧方便的工具——集算器,通过使用集算器可以将文本日志变成结构化数据,然后可以使用SQL式查询。集算器利用集算语言的优点,将日志内容结构化为数据表结构,SPL支持直接对结构化的文件进行SQL查询,不再需要安装配置第三方数据库软件。本文还详细介绍了具体的实施过程。 ... [详细]
  • STL迭代器的种类及其功能介绍
    本文介绍了标准模板库(STL)定义的五种迭代器的种类和功能。通过图表展示了这几种迭代器之间的关系,并详细描述了各个迭代器的功能和使用方法。其中,输入迭代器用于从容器中读取元素,输出迭代器用于向容器中写入元素,正向迭代器是输入迭代器和输出迭代器的组合。本文的目的是帮助读者更好地理解STL迭代器的使用方法和特点。 ... [详细]
  • 本文介绍了5个基本Linux命令行工具的现代化替代品,包括du、top和ncdu。这些替代品在功能上进行了改进,提高了可用性,并且适用于现代化系统。其中,ncdu是du的替代品,它提供了与du类似的结果,但在一个基于curses的交互式界面中,重点关注占用磁盘空间较多的目录。 ... [详细]
  • 2019独角兽企业重金招聘Python工程师标准
    本文介绍了2019独角兽企业对Python工程师的招聘标准,包括在AndroidManifest中定义meta-data的方法和获取meta-data值的代码。同时提供了获取meta-data值的具体实现方法。转载文章链接:https://my.oschina.net/u/244918/blog/685127 ... [详细]
  • 本文详细介绍了在ASP.NET中获取插入记录的ID的几种方法,包括使用SCOPE_IDENTITY()和IDENT_CURRENT()函数,以及通过ExecuteReader方法执行SQL语句获取ID的步骤。同时,还提供了使用这些方法的示例代码和注意事项。对于需要获取表中最后一个插入操作所产生的ID或马上使用刚插入的新记录ID的开发者来说,本文提供了一些有用的技巧和建议。 ... [详细]
  • 本文介绍了游标的使用方法,并以一个水果供应商数据库为例进行了说明。首先创建了一个名为fruits的表,包含了水果的id、供应商id、名称和价格等字段。然后使用游标查询了水果的名称和价格,并将结果输出。最后对游标进行了关闭操作。通过本文可以了解到游标在数据库操作中的应用。 ... [详细]
  • ALTERTABLE通过更改、添加、除去列和约束,或者通过启用或禁用约束和触发器来更改表的定义。语法ALTERTABLEtable{[ALTERCOLUMNcolu ... [详细]
  • 本文介绍了iOS数据库Sqlite的SQL语句分类和常见约束关键字。SQL语句分为DDL、DML和DQL三种类型,其中DDL语句用于定义、删除和修改数据表,关键字包括create、drop和alter。常见约束关键字包括if not exists、if exists、primary key、autoincrement、not null和default。此外,还介绍了常见的数据库数据类型,包括integer、text和real。 ... [详细]
  • 本文介绍了栈和队列的区别及其特点。栈是一种先进后出的线性表,只能在表的一端进行插入和删除操作;队列是一种先进先出的线性表,只能在表的一端进行插入和在另一端进行删除操作。栈和队列是两种广泛使用的线性数据结构,它们的基本操作具有特殊性。栈的遍历需要遍历整个栈才能取出数据,并需要为数据开辟临时空间,而队列基于地址指针进行遍历,可以从头或尾部开始遍历,但不能同时遍历,且无需开辟临时空间。栈和队列在程序设计中具有重要应用。 ... [详细]
  • 本文介绍了Java中Hashtable的clear()方法,该方法用于清除和移除指定Hashtable中的所有键。通过示例程序演示了clear()方法的使用。 ... [详细]
author-avatar
jesusestella
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有