2. 程式人生 > >MySQL之Innodb恢復的學習筆記

MySQL之Innodb恢復的學習筆記

阿新 • • 發佈：2018-10-29
idle oba not run nag recv cts 相對 nor 長度

MySQL · 引擎特性 · InnoDB 崩潰恢復過程

enum {
    SRV_FORCE_IGNORE_CORRUPT = 1,    /*!< let the server run even if it
                    detects a corrupt page */
    SRV_FORCE_NO_BACKGROUND    = 2,    /*!< prevent the main thread from
                    running: if a crash would occur
                    in purge, this prevents it */
    SRV_FORCE_NO_TRX_UNDO = 3,    /*!< do not run trx rollback after
                    recovery */
    SRV_FORCE_NO_IBUF_MERGE = 4,    /*!< prevent also ibuf operations:
                    if they would cause a crash, better
                    not do them */
    SRV_FORCE_NO_UNDO_LOG_SCAN = 5,    /*!< do not look at undo logs when
                    starting the database: InnoDB will
                    treat even incomplete transactions
                    as committed */
    SRV_FORCE_NO_LOG_REDO = 6    /*!< do not do the log roll-forward
                    in connection with recovery */
};

innodb中的 3個lsn

innodb的lsn和oracle的scn一樣，是一個重要的概念。比如

  • 在flush list中正是是使用low lsn作為鏈表的條件
    參考buf_page_t中的lsn_t oldest_modification;
  • 在checkpoint中記錄的也是lsn
    參考宏
#define LOG_CHECKPOINT_NO        0
#define LOG_CHECKPOINT_LSN        8
#define LOG_CHECKPOINT_OFFSET        16
#define LOG_CHECKPOINT_LOG_BUF_SIZE    24
  • 在物理文件中每個塊最後的刷新lsn
    參考宏FIL_PAGE_LSN
  • 在寫日誌落盤的時候也是以lsn為標準的
    參考函數log_write_up_to

實際上lsn就是表示的日誌量的字節數，是一個累加的值，在5.7中表現為:

/* Type used for all log sequence number storage and arithmetics */
typedef    ib_uint64_t        lsn_t;

及一個8字節非負的整數。最大值及2的64次方。有了這種物理上概念，lsn很容易換算為當前日誌的偏移量。

下面描述一下和檢查點相關的幾個lsn

  • ibdata第一個塊FIL中的lsn(flush lsn):ibdata的26後面8字節是在innodb 幹凈關閉的時候進行更新的，如果不正常關閉不會進行寫入(FIL_PAGE_FILE_FLUSH_LSN)
  • redolog中MLOG_CHECKPOINT的lsn: redolog MLOG_CHECKPOINT lsn的寫入是在每次checkpoint的時候同步寫入的.幹凈關閉會更新。
  • redolog header中的lsn:是在每次checkpoint的時候異步寫入的在MLOG_CHECKPOINT寫入之後.幹凈關閉會更新。
    我們表示為lsn1/lsn2/lsn3

正常關閉3個lsn是相等的，如果非正常關閉innodb,lsn1不會更新，因此lsn3必然不和lsn1相等，則判定需要進行carsh recovery。

if (checkpoint_lsn != flush_lsn) {

    ......
        if (!recv_needed_recovery) {

            ib::info() << "The log sequence number " << flush_lsn
                << " in the system tablespace does not match"
                " the log sequence number " << checkpoint_lsn
                << " in the ib_logfiles!"; //出現這個警告說明需要恢復了，因為沒有幹凈的關閉數據庫，那麽flush_lsn一定比checkpoint_lsn小

            if (srv_read_only_mode) {
                ib::error() << "Can‘t initiate database"
                    " recovery, running in read-only-mode.";
                log_mutex_exit();
                return(DB_READ_ONLY);
            }
            recv_init_crash_recovery(); //初始化
        }
    }

MLOG_CHECKPOINT

  • log_checkpoint 函數由master線程調用，以及關閉數據庫的時候調用，不斷的向redo log中寫入MLOG_CHECKPOINT和MLOG_FILE_NAME

log_group_checkpoint 寫入checkpoint信息到log header

#0  mtr_t::commit_checkpoint (this=0x7fff761fb830, checkpoint_lsn=697558445) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/mtr/mtr0mtr.cc:592
#1  0x0000000001ceb4b9 in fil_names_clear (lsn=697558445, do_write=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/fil/fil0fil.cc:7067
#2  0x0000000001a521cc in log_checkpoint (sync=true, write_always=false) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1927
#3  0x0000000001b856f2 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2596
#4  0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744
#5  0x0000003f74807aa1 in start_thread () from /lib64/libpthread.so.0
#6  0x0000003f740e8bcd in clone () from /lib64/libc.so.6

正常innodb運行的情況下 checkpoint是由master線程觸發。我們知道臟數據通過page clean線程和lru manager線程是在不斷寫盤的，那麽在進行異常重啟的的時候我們必須要知道一個恢復的起點，但是這個起點是不能記錄在內存中必要固化到磁盤，恢復的時候讀取這個點以後的redo進行恢復，而checkpoint就是完成這個事情下面是checkpoint的執行流程。

正常情況下master會每秒進行檢查點其作用有:(參考log_checkpoint函數)
1、檢查是否有自上次檢查點以來的臟數據寫盤了
2、如果有則在redo裏面會為每個修改過的文件寫入MLOG_FILE_NAME,完成後寫入一個總的MLOG_CHECKPOINT(參考fil_names_clear函數)
MLOG_FILE_NAME主要記錄至上次檢查點以來更改過的數據文件
MLOG_CHECKPOINT主要記錄檢查點的lsn
3、如果有則在redo header中寫入相應的檢查點信息包含(異步寫)(參考log_group_checkpoint函數)

Log sequence number 697794162
Log flushed up to 697794162
Pages flushed up to 697794162
Last checkpoint at 697794153

697794162-697794153 = 9 剛好是MLOG_CHECKPOINT的長度
oldest_lsn <= log_sys->last_checkpoint_lsn + SIZE_OF_MLOG_CHECKPOINT
SIZE_OF_MLOG_CHECKPOINT=9

redo的寫入有6個途徑:
1、master 線程每秒調用 棧幀(可能是idle可能是active 和檢測是否需要插入緩存合並有關)
2、master 線程每秒checkpoint調用 (可能是idle可能是active 和檢測是否需要插入緩存合並有關)
3、page clean 線程調用 棧幀 / Force the log to the disk before writing the modified block /
4、主線程commit 調用 棧幀
5、innodb shutdown
6、redo buffer不足

1、master線程調用 棧幀(可能是idle可能是active 和檢測是否需要插入緩存合並有關)

#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5b38000 "\200\024", len=512, pad_len=0, start_lsn=697764864, new_data_offset=166)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697765068, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001a51163 in log_buffer_sync_in_background (flush=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1553
#3  0x0000000001b84bd1 in srv_sync_log_buffer_in_background () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2312
#4  0x0000000001b85666 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2586
#5  0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744

2、master 線程checkpoint調用 (可能是idle可能是active 和檢測是否需要插入緩存合並有關)

#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000 "\200\024\002", len=1024, pad_len=0, start_lsn=697789952, new_data_offset=139)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697790725, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001a52247 in log_checkpoint (sync=true, write_always=false) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1934
#3  0x0000000001b856f2 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2596
#4  0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744

3、page clean 線程調用 棧幀 / Force the log to the disk before writing the modified block /

#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000 "\200\024\002", len=13312, pad_len=1024, start_lsn=697778176, new_data_offset=468)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697790015, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001c704c7 in buf_flush_write_block_low (bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, sync=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1035
#3  0x0000000001c70cea in buf_flush_page (buf_pool=0x33247d8, bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, sync=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1237
#4  0x0000000001c717f4 in buf_flush_try_neighbors (page_id=..., flush_type=BUF_FLUSH_LIST, n_flushed=0, n_to_flush=25)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1466
#5  0x0000000001c71b57 in buf_flush_page_and_try_neighbors (bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, n_to_flush=25, count=0x7fffa02867c0)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1558
#6  0x0000000001c72862 in buf_do_flush_list_batch (buf_pool=0x33247d8, min_n=25, lsn_limit=18446744073709551615)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1846
#7  0x0000000001c72cb6 in buf_flush_batch (buf_pool=0x33247d8, flush_type=BUF_FLUSH_LIST, min_n=25, lsn_limit=18446744073709551615)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1926
#8  0x0000000001c73104 in buf_flush_do_batch (buf_pool=0x33247d8, type=BUF_FLUSH_LIST, min_n=25, lsn_limit=18446744073709551615, n_processed=0x7fffa0286938)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:2071
#9  0x0000000001c734ee in buf_flush_lists (min_n=25, lsn_limit=18446744073709551615, n_processed=0x7fffa02869c8)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:2202
#10 0x0000000001c76a97 in buf_flush_page_cleaner_coordinator (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:3362

4、主線程commit 調用 棧幀

#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000 "\200\024\002", len=2560, pad_len=0, start_lsn=697762816, new_data_offset=230)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697765030, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001a51087 in log_buffer_flush_to_disk (sync=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1524
#3  0x00000000019a9157 in innobase_flush_logs (hton=0x2e9fdd0, binlog_group_flush=true)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:4407
#4  0x0000000000f65893 in flush_handlerton (thd=0x0, plugin=0x7ffff03588e8, arg=0x7ffff0358944) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:2606
#5  0x00000000015d7716 in plugin_foreach_with_mask (thd=0x0, func=0xf65835 <flush_handlerton(THD*, plugin_ref, void*)>, type=1, state_mask=4294967287, 
    arg=0x7ffff0358944) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:2318
#6  0x0000000000f658ef in ha_flush_logs (db_type=0x0, binlog_group_flush=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:2617
#7  0x000000000185733d in MYSQL_BIN_LOG::process_flush_stage_queue (this=0x2e02c80, total_bytes_var=0x7ffff0358a88, rotate_var=0x7ffff0358a87, 
    out_queue_var=0x7ffff0358a78) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8541
#8  0x000000000185899f in MYSQL_BIN_LOG::ordered_commit (this=0x2e02c80, thd=0x7fff2c000b70, all=false, skip_commit=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9189
#9  0x000000000185700c in MYSQL_BIN_LOG::commit (this=0x2e02c80, thd=0x7fff2c000b70, all=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8440
#10 0x0000000000f63df8 in ha_commit_trans (thd=0x7fff2c000b70, all=false, ignore_global_read_lock=false)

入口函數
innobase_start_or_create_for_mysql

recv_recovery_from_checkpoint_start

1、此函數需要輸入flush的lsn及臟數據寫入到的位置

這個數據從FIL_PAGE_FILE_FLUSH_LSN中讀取，這個值
只在ibdata的第一個page有效其他均為0,他的讀取來自於
函數Datafile::validate_first_page，
其中
*flush_lsn = mach_read_from_8(
m_first_page + FIL_PAGE_FILE_FLUSH_LSN);


其寫入由函數  正常shutdown才會寫入,非正常關閉不會寫入，正常運行檢查點也不會寫入
fil_write_flushed_lsn 寫入
mach_write_to_8(buf + FIL_PAGE_FILE_FLUSH_LSN, lsn);

棧幀
    #0  fil_write_flushed_lsn (lsn=696973727) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/fil/fil0fil.cc:1946
    #1  0x0000000001a538a7 in logs_empty_and_mark_files_at_shutdown () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:2464
    #2  0x0000000001b915a9 in innobase_shutdown_for_mysql () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0start.cc:2803
    #3  0x00000000019a8ffc in innobase_end (hton=0x2e9edd0, type=HA_PANIC_CLOSE) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:4360
    #4  0x0000000000f62621 in ha_finalize_handlerton (plugin=0x3015cd0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:813
    #5  0x00000000015d3d25 in plugin_deinitialize (plugin=0x3015cd0, ref_check=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:995
    #6  0x00000000015d410e in reap_plugins () at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:1077
    #7  0x00000000015d6073 in plugin_shutdown () at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:1845
    #8  0x0000000000ebf7eb in clean_up (print_message=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/mysqld.cc:1336
    #9  0x0000000000ec701b in mysqld_main (argc=98, argv=0x2e9cf08) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/mysqld.cc:5386
    #10 0x0000000000ebd604 in main (argc=10, argv=0x7fffffffe458) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/main.cc:25

2、此函數首先建立紅黑樹用於恢復並且做 force recovery判斷

   (srv_force_recovery >= SRV_FORCE_NO_LOG_REDO) 
   然後調用 
   recv_find_max_checkpoint 此函數就是找到最大的checkpoint lsn、redo文件,以及field 就是相對於一個日誌而講所在的offset set (512*1 or 512*3)_
   讀取如下：
                   group->lsn = mach_read_from_8(
                  buf + LOG_CHECKPOINT_LSN);
                group->lsn_offset = mach_read_from_8(
                  buf + LOG_CHECKPOINT_OFFSET);
                checkpoint_no = mach_read_from_8(
                  buf + LOG_CHECKPOINT_NO);

3、recv_group_scan_log_recs

   循環讀取64K(RECV_SCAN_SIZE)日誌到redo buffer(log_group_read_log_seg)
   recv_scan_log_recs
     本函數將64K 的redo 通過每個512 bytes block大小循環加入到(recv_sys_add_to_parsing_buf) 掃描到parse buffer 
     代碼片段拷貝
          ut_memcpy(recv_sys->buf + recv_sys->len,
              log_block + start_offset, end_offset - start_offset);
            
           當每次掃描了64K*80的日誌量的時候會輸出，級5M
           ib::info() << "Doing recovery: scanned up to"
                " log sequence number " << scanned_lsn;
     並且進行分析對這加入到 parse buffer的日誌進行分析(recv_parse_log_recs) /其中parse buffer 為2M(宏RECV_PARSING_BUF_SIZE大小)
        recv_parse_log_recs函數對每次加入 parse buffer的64k進行分析主要分析是MLOG_SINGLE_REC_FLAG還是MLOG_MULTI_REC_END 同時確認MLOG_MULTI_REC_END
        是否完整，完成後加入到hash table，函數是調用recv_parse_log_rec進行 (type spaceid page_no data)的剝離。

那麽recv_group_scan_log_recs為第一層循環，循環掃描64K日誌到redo buffer
然後調用recv_scan_log_recs以block單位(512b)大小循環加入到parse buffer，這是通過函數recv_sys_add_to_parsing_buf完成
等到64k加入到parse buffer後調用recv_parse_log_recs函數對每次加入 parse buffer的64k進行分析，分析是循環以record為單位的，主要分析MLOG_SINGLE_REC_FLAG還是MLOG_MULTI_REC_END，同時確保MLOG_MULTI_REC_END記錄是完整的。完成後recv_parse_log_recs函數 還要將其加入到hash table函數為recv_add_to_hash_table，本函數是通過recv_parse_log_rec進行 (type spaceid page_no data)的剝離。

recv_apply_hashed_log_recs 最後完成分析完成後的日誌應用，從hash table中

MySQL之Innodb恢復的學習筆記

相關推薦

MySQL之Innodb恢復的學習筆記

idle oba not run nag recv cts 相對 nor 長度 MySQL · 引擎特性 · InnoDB 崩潰恢復過程 enum { SRV_FORCE_IGNORE_CORRUPT = 1, /*!< let the server r

MySQL之InnoDB索引面試學習筆記

family 技術分享 ron myisam 不同 索引數據 想要 math 減少 寫在前面 　　想要做好後臺開發，終究是繞不過索引這一關的。先問自己一個問題，InnoDB為什麽選擇B+樹作為默認索引結構。本文主要參考MySQL索引背後的數據結構及算法原理和剖析Mysql

Mysql備份恢復學習筆記

重復 環境 rest sed 關閉 top 啟動 emctl trab xtrabackup 物理備份+binlog 完整備份 創建備份目錄：#mkdir /back/full備份：#innobackupex --user=root --password=‘123‘ /b

《深入淺出MySQL:資料庫開發、優化與管理維護(2nd)》第31章之MySQL非同步複製搭建學習筆記

MySQL的複製原理大致如下： （1）首先，MySQL主庫在事務提交時會把資料變更作為事件Events記錄在二進位制日誌檔案Binlog中；MySQL主庫上的sync_binlog引數控制Binlog日誌重新整理到磁碟。 （2）主庫推送二進位制日誌檔案Binlog中的事件到從庫的中繼日誌Re

mysql學習之旅----基礎學習筆記

資料持久化就是要儲存資料到檔案可以是資料庫，可以是文字等 推薦下載msi的安裝包，可以做許多環境配置的事 查詢select username,age,gender from users; 增加insert into users(username,age,gender) values ('我',28,

react之redux的學習筆記

reac http npm 狀態 flux 比較 ins install sta 主流的數據框架：Flux （單向數據量，比較重大，實用性不強） reFlux redux（簡單 單一狀態樹） mvc model: 數據 view: 顯示 controller: 管理（act

mysql之innodb引擎使用方法

mysql之innodb引擎使用方法前言閑來無事做不如MySQL。一.簡介:1.Linux下使用MySQL數據庫時,為了支持事務操作需要用到InnoDB引擎,對於表中處理的插入,更新等操作失敗時,回滾前面不應該完成的操作是必須的. 2.一般MySQL默認的數據庫引擎是MyISAM,不支持事務和外鍵,則可使用支

C#中面向對象編程機制之多態學習筆記

tel codes var pub tools 不同 線程同步 dddddd 圖形 C#的多態性： 我的理解是：同一個操作，作用於不同的對象時，會有不同的結果，即同一個方法根據需要，作用於不同的對象時，會有不同的實現。 C#的多態包括：接口多態，繼承多態。 其中繼

MySQL 連接查詢 學習筆記

返回 oss employee code 交叉連接 記錄 pre 從表 外連接 #交叉連接（返回笛卡爾交集）AXB={（a,b)|a屬於A且b屬於B },則AXB所形成的集合就叫笛卡爾集 1 SELECT * from employees cross join depts

HBase、HIVE、MYSQL數據庫學習筆記

reduce 搜索 oop nosql數據庫 組織 AS sdn 除了 hdfs HBase 1、hbase為查詢而生，它通過組織機器的內存，提供一個超大的內存hash表，它需要組織自己的數據結構，表在hbase中是物理表，而不是邏輯表，搜索引擎用它來存儲索引，以滿足實時

MySql cmd下的學習筆記 —— 有關表的操作（增，刪，改，查）

strong .com nsh utf str tab 主鍵 test har （知識回顧） 連接數據庫 mysql -uroot -p111 先建立一個新庫 create database test1; use test1; 由於今天的主要內容是表的操作，建立表的詳細過

MySql cmd下的學習筆記 —— 有關建立表的操作（有關與數據類型）

字符串 聲明 span tro img float info 學習 可能 （01）建表的過程實際上是 聲明字段 的過程 　　　一. 列類型（字段）： 　　　　　存儲同樣的數據時，不同的列類型，所占據的空間和效率是不一樣的，這就是建表時要考慮的意義。 　　　二.MySQL三大

10-C++遠征之模板篇-學習筆記

字符串鍵 什麽 如果 containe 代碼示例 默認 顯示 函數重載 由於 C++遠征之模板篇 將會學到的內容： 模板函數 & 模板類 -> 標準模板類 友元函數 & 友元類 靜態數據成員 & 靜態成員函數 運算符重載: 一切皆有可能 友

MySql cmd下的學習筆記 —— 有關多表查詢的操作（多表查詢練習題及union操作）

image ins myisam name sam row div mysq gin 先建立一張 m 表 mysql> create table m ( -> mid int, -> hid int, -> gid in

MySql cmd下的學習筆記 —— 有關視圖的操作（algorithm）

mysql merge bubuko png define 情況 什麽 必須 臨時 建立一張簡單的查詢視圖，不用臨時表，只用條件合並 在簡單的查詢中，建立臨時表的開銷比較大 這是可以指定algorithm選項為merge 在v2的視圖中，並沒有建立臨時表 但在下

java反射之動態代理學習筆記

ace ins 功能 運行 invoke -- ram lang glib 動態代理概述：代理：本來自己做的事情，請別人來做，被請的人就是代理對象；舉例：春節回家買票讓人代理買動態代理：在程序運行過程中產生的這個對象，而程序運行過程中產生對象其實就是我們剛才反射講解的內容，

MySQL多表查詢-學習筆記

交叉連線 1. 集合：無序性、唯一性 兩個集合的元素相乘，成為笛卡爾積 設集合A有M個數據，M個數據各不相同 集合B有N個數據，N個數據各不相同 笛卡兒積：MN 表A有9行，表B有10行，笛卡兒積為90行 等值連線 2(1)得到兩個2表的笛卡兒積，表之間用逗號或者join或者cross jo

資料結構與演算法之美專欄學習筆記-排序(上）

排序方法 氣泡排序、插入排序、選擇排序、快速排序、歸併排序、計數排序、基數排序、桶排序。   複雜度歸類 氣泡排序、插入排序、選擇排序 O(n^2) 快速排序、歸併排序 O(nlogn) 計數排序、基數排序、桶排序 O(n)     演算法的執行效率 1. 最

資料庫MySQL基礎語法的學習筆記

目錄   1.進入資料庫 2.建立資料庫 3.建立資料表 4.資料型別 5.表的增刪修改操作 6.查詢的擴充套件 7.表的修改、 8.表的複製   1.進入資料庫 找出自己主機資料庫的位置，再使用Dos.指令進入自己主機的資料庫

mysql之innodb鎖的應用

--> mysql行鎖  表的搜尋引擎為innodb，支援事務，採用的是行鎖。 ---> 首先將mysql 的自動提交設定為0 set autocommit = 0;  寫輸入完成sql之後需要執行的命令是 commit;命令來執行事務的提交。