主頁 > 資料庫 > 關系型資料庫速度比較(性能基準測驗)及python實作

關系型資料庫速度比較(性能基準測驗)及python實作

2023-06-27 09:13:23 資料庫

https://www.sqlite.org/speed.html 做了SQLite、MySQL和PostgreSQL的速度比較，使用的資料庫版本比較老，但是測驗方法依舊頗有意義，

小結

我們進行了一系列的測驗來衡量SQLite 2.7.6、PostgreSQL 7.1.3和MySQL 3.23.41的相對性能，以下是從這些實驗中得出的一般結論：

  • SQLite 2.7.6比RedHat 7.2上默認安裝的PostgreSQL 7.1.3在大多數常用操作上要快得多（有時快10或20倍），

  • 在大多數常見操作中，SQLite 2.7.6通常比MySQL 3.23.41快（有時快兩倍以上），

  • SQLite執行CREATE INDEX或DROP TABLE的速度不如其他資料庫，但影響不大，因為這些都是不常見操作，

  • 將多個操作組合成事務時SQLite的作業效果最好，

測驗說明：

  • 不涉及多用戶性能或涉及多個連接和子查詢的復雜查詢的優化，
  • 在相對較小（大約14兆位元組）的資料庫上進行的，

測驗環境

用于這些測驗的平臺是一臺1.6GHz的Athlon，有1GB的記憶體和一個IDE磁盤驅動器，作業系統是RedHat Linux 7.2，stock內核，

使用的PostgreSQL和MySQL服務器是RedHat 7.2上默認提供的（PostgreSQL版本7.1.3和MySQL版本3.23.41），特別注意的是，RedHat 7.2上的默認MySQL配置不支持事務，不支持事務給了MySQL很大的速度優勢，但SQLite在大多數測驗中仍然能夠領先，

RedHat 7.3中的默認PostgreSQL配置太保守（它是為在8MB記憶體的機器上作業而設計的），通過配置調整，可以使PostgreSQL運行得快得多，Matt Sergeant報告說，他已經調整了他的PostgreSQL安裝，結果顯示，PostgreSQL和MySQL的運行速度基本相同，他對SQLite進行了測驗，其配置與網站上出現的相同，它是用-O6優化和-DNDEBUG=1開關編譯的，該開關禁用了SQLite代碼中的許多 "assert() "陳述句，-DNDEBUG=1編譯器選項使SQLite的速度大約提高了一倍，

一個簡單的Tcl腳本被用來生成和運行所有的測驗，這個Tcl腳本的副本可以在SQLite源代碼樹中的tools/speedtest.tcl檔案中找到，

測驗

測驗1：1000個INSERT

CREATE TABLE t1(a INTEGER, b INTEGER, c VARCHAR(100));
INSERT INTO t1 VALUES(1,13153,'thirteen thousand one hundred fifty three');
INSERT INTO t1 VALUES(2,75560,'seventy five thousand five hundred sixty');
... 995 lines omitted
INSERT INTO t1 VALUES(998,66289,'sixty six thousand two hundred eighty nine');
INSERT INTO t1 VALUES(999,24322,'twenty four thousand three hundred twenty two');
INSERT INTO t1 VALUES(1000,94142,'ninety four thousand one hundred forty two');
  • 結果：
| PostgreSQL:            | 4.373  |
| ---------------------- | ------ |
| MySQL:                 | 0.114  |
| SQLite 2.7.6:          | 13.061 |
| SQLite 2.7.6 (nosync): | 0.223  |

因為它沒有中央服務器來協調訪問，所以SQLite必須為每個事務關閉和重新打開資料庫檔案，從而使其快取失效，在這個測驗中，每個SQL陳述句都是一個單獨的事務，所以資料庫檔案必須被打開和關閉，快取必須被重繪1000次，盡管這樣，SQLite的異步版本仍然幾乎和MySQL一樣快，然而，請注意同步版本的速度要慢得多，SQLite在每個同步事務之后呼叫fsync()，以確保所有資料在繼續之前安全地在磁盤表面，在同步測驗的13秒中，SQLite大部分時間都在閑置，等待磁盤I/O的完成，

測驗2：事務中的25000個INSERT

BEGIN;
CREATE TABLE t2(a INTEGER, b INTEGER, c VARCHAR(100));
INSERT INTO t2 VALUES(1,59672,'fifty nine thousand six hundred seventy two');
... 24997 lines omitted
INSERT INTO t2 VALUES(24999,89569,'eighty nine thousand five hundred sixty nine');
INSERT INTO t2 VALUES(25000,94666,'ninety four thousand six hundred sixty six');
COMMIT;
  • 結果：
| PostgreSQL:            | 4.900 |
| ---------------------- | ----- |
| MySQL:                 | 2.184 |
| SQLite 2.7.6:          | 0.914 |
| SQLite 2.7.6 (nosync): | 0.757 |

當所有的INSERT被放在事務中時，SQLite不再需要關閉和重新打開資料庫，不需要做任何fsync()，SQLite比PostgreSQL和MySQL都快得多，

測驗3：25000次INSERT到有索引的表中

BEGIN;
CREATE TABLE t3(a INTEGER, b INTEGER, c VARCHAR(100));
CREATE INDEX i3 ON t3(c);
... 24998 lines omitted
INSERT INTO t3 VALUES(24999,88509,'eighty eight thousand five hundred nine');
INSERT INTO t3 VALUES(25000,84791,'eighty four thousand seven hundred ninety one');
COMMIT;
  • 結果：
| PostgreSQL:            | 8.175 |
| ---------------------- | ----- |
| MySQL:                 | 3.197 |
| SQLite 2.7.6:          | 1.555 |
| SQLite 2.7.6 (nosync): | 1.402 |

有報告稱，SQLite在索引表上的表現不盡人意，最近增加了這個測驗來反駁這些傳言，誠然，SQLite在創建新的索引項時不如其他引擎快（見下面的測驗6），但其總體速度仍較好，

測驗4：100個沒有索引的SELECT

BEGIN;
SELECT count(*), avg(b) FROM t2 WHERE b>=0 AND b<1000;
SELECT count(*), avg(b) FROM t2 WHERE b>=100 AND b<1100;
... 96 lines omitted
SELECT count(*), avg(b) FROM t2 WHERE b>=9800 AND b<10800;
SELECT count(*), avg(b) FROM t2 WHERE b>=9900 AND b<10900;
COMMIT;
  • 結果：
| PostgreSQL:            | 3.629 |
| ---------------------- | ----- |
| MySQL:                 | 2.760 |
| SQLite 2.7.6:          | 2.494 |
| SQLite 2.7.6 (nosync): | 2.526 |

這個測驗對沒有索引的25000條目表進行了100次查詢，因此需要進行全表掃描，先前版本的SQLite在這個測驗中曾經比PostgreSQL和MySQL慢，但最近的性能增強提高了它的速度，所以它現在是這一組中最快的，

測驗5：100次模糊SELECT

BEGIN;
SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%one%';
SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%two%';
... 96 lines omitted
SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%ninety nine%';
SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%one hundred%';
COMMIT;
  • 結果：
| PostgreSQL:            | 13.409 |
| ---------------------- | ------ |
| MySQL:                 | 4.640  |
| SQLite 2.7.6:          | 3.362  |
| SQLite 2.7.6 (nosync): | 3.372  |

這個測驗進行100次全表掃描，但它使用了字串比較而不是數字比較，SQLite在這里比PostgreSQL快三倍以上，比MySQL快30%左右，

測驗6：創建索引

CREATE INDEX i2a ON t2(a);
CREATE INDEX i2b ON t2(b);
  • 結果：
| PostgreSQL:            | 0.381 |
| ---------------------- | ----- |
| MySQL:                 | 0.318 |
| SQLite 2.7.6:          | 0.777 |
| SQLite 2.7.6 (nosync): | 0.659 |

SQLite在創建新索引時比較慢，問題不大（因為新索引的創建并不頻繁），且正在努力解決的問題，希望未來的SQLite版本在這方面能做得更好，

測驗7：5000個帶索引的SELECT

SELECT count(*), avg(b) FROM t2 WHERE b>=0 AND b<100;
SELECT count(*), avg(b) FROM t2 WHERE b>=100 AND b<200;
SELECT count(*), avg(b) FROM t2 WHERE b>=200 AND b<300;
... 4994 lines omitted
SELECT count(*), avg(b) FROM t2 WHERE b>=499700 AND b<499800;
SELECT count(*), avg(b) FROM t2 WHERE b>=499800 AND b<499900;
SELECT count(*), avg(b) FROM t2 WHERE b>=499900 AND b<500000;
  • 結果：
| PostgreSQL:            | 4.614 |
| ---------------------- | ----- |
| MySQL:                 | 1.270 |
| SQLite 2.7.6:          | 1.121 |
| SQLite 2.7.6 (nosync): | 1.162 |

這三個資料庫引擎在有索引作業時都運行得更快，但SQLite仍然是最快的，

測驗8：1000次無索引的UPDATE操作

BEGIN;
UPDATE t1 SET b=b*2 WHERE a>=0 AND a<10;
UPDATE t1 SET b=b*2 WHERE a>=10 AND a<20;
... 996 lines omitted
UPDATE t1 SET b=b*2 WHERE a>=9980 AND a<9990;
UPDATE t1 SET b=b*2 WHERE a>=9990 AND a<10000;
COMMIT;
  • 結果：
| PostgreSQL:            | 1.739 |
| ---------------------- | ----- |
| MySQL:                 | 8.410 |
| SQLite 2.7.6:          | 0.637 |
| SQLite 2.7.6 (nosync): | 0.638 |

MySQL始終比PostgreSQL和SQLite慢五到十倍，MySQL通常是非常快的引擎，也許這個問題在后來的MySQL版本中已經解決了，

測驗9：帶索引的25000次UPDATE

BEGIN;
UPDATE t2 SET b=468026 WHERE a=1;
UPDATE t2 SET b=121928 WHERE a=2;
... 24996 lines omitted
UPDATE t2 SET b=35065 WHERE a=24999;
UPDATE t2 SET b=347393 WHERE a=25000;
COMMIT;
  • 結果：
| PostgreSQL:            | 18.797 |
| ---------------------- | ------ |
| MySQL:                 | 8.134  |
| SQLite 2.7.6:          | 3.520  |
| SQLite 2.7.6 (nosync): | 3.104  |

在最近的2.7.0版本中，SQLite在這項測驗中的運行速度與MySQL大致相同，但最近對SQLite的優化使UPDATEs的速度提高了一倍多，

測驗10：帶索引的25000個文本UPDATE

BEGIN;
UPDATE t2 SET c='one hundred forty eight thousand three hundred eighty two' WHERE a=1;
UPDATE t2 SET c='three hundred sixty six thousand five hundred two' WHERE a=2;
... 24996 lines omitted
UPDATE t2 SET c='three hundred eighty three thousand ninety nine' WHERE a=24999;
UPDATE t2 SET c='two hundred fifty six thousand eight hundred thirty' WHERE a=25000;
COMMIT;
  • 結果：
| PostgreSQL:            | 48.133 |
| ---------------------- | ------ |
| MySQL:                 | 6.982  |
| SQLite 2.7.6:          | 2.408  |
| SQLite 2.7.6 (nosync): | 1.725  |

在這里，2.7.0版的SQLite曾經以與MySQL差不多的速度運行，但現在2.7.6版比MySQL快2倍以上，比PostgreSQL快20倍以上，

測驗11：來自SELECT的INSERT

BEGIN;
INSERT INTO t1 SELECT b,a,c FROM t2;
INSERT INTO t2 SELECT b,a,c FROM t1;
COMMIT;
  • 結果：
| PostgreSQL:            | 61.364 |
| ---------------------- | ------ |
| MySQL:                 | 1.537  |
| SQLite 2.7.6:          | 2.787  |
| SQLite 2.7.6 (nosync): | 1.599  |

異步的SQLite只比MySQL慢一絲，(MySQL似乎特別擅長INSERT...SELECT陳述句，)PostgreSQL引擎的大部分時間是在等待磁盤I/O，

測驗12：沒有索引的DELETE

DELETE FROM t2 WHERE c LIKE '%fifty%';
  • 結果：
| PostgreSQL:            | 1.509 |
| ---------------------- | ----- |
| MySQL:                 | 0.975 |
| SQLite 2.7.6:          | 4.004 |
| SQLite 2.7.6 (nosync): | 0.560 |

同步版本的SQLite是一組中最慢的，但異步版本是最快的，差別在于執行fsync()所需的額外時間，

測驗13：帶索引的DELETE

DELETE FROM t2 WHERE a>10 AND a<20000;
  • 結果：
| PostgreSQL:            | 1.316 |
| ---------------------- | ----- |
| MySQL:                 | 2.262 |
| SQLite 2.7.6:          | 2.068 |
| SQLite 2.7.6 (nosync): | 0.752 |

PostgreSQL比MySQL快，然而，異步的SQLite比另外兩個都快，

測驗14：大的DELETE之后再大的INSERT

INSERT INTO t2 SELECT * FROM t1;
  • 結果：
| PostgreSQL:            | 13.168 |
| ---------------------- | ------ |
| MySQL:                 | 1.815  |
| SQLite 2.7.6:          | 3.210  |
| SQLite 2.7.6 (nosync): | 1.485  |

舊版本的SQLite（在2.4.0版本之前）在一連串的DELETE和新的INSERT之后會顯示出性能下降，如本測驗所示，這個問題現在已經解決了，

測驗15：大的DELETE后大量小INSERT

BEGIN;
DELETE FROM t1;
INSERT INTO t1 VALUES(1,10719,'ten thousand seven hundred nineteen');
... 11997 lines omitted
INSERT INTO t1 VALUES(11999,72836,'seventy two thousand eight hundred thirty six');
INSERT INTO t1 VALUES(12000,64231,'sixty four thousand two hundred thirty one');
COMMIT;
  • 結果：
| PostgreSQL:            | 4.556 |
| ---------------------- | ----- |
| MySQL:                 | 1.704 |
| SQLite 2.7.6:          | 0.618 |
| SQLite 2.7.6 (nosync): | 0.406 |

SQLite非常善于在事務中進行INSERT，它在這項測驗中比其他資料庫快很多，

測驗16：DROP表

DROP TABLE t1;
DROP TABLE t2;
DROP TABLE t3;
  • 結果：
| PostgreSQL:            | 0.135 |
| ---------------------- | ----- |
| MySQL:                 | 0.015 |
| SQLite 2.7.6:          | 0.939 |
| SQLite 2.7.6 (nosync): | 0.254 |

SQLite比其他資料庫要慢，它必須經過并洗掉資料庫檔案中涉及該表的記錄，另一方面，MySQL和PostgreSQL使用單獨的檔案來表示每個表，所以它們可以通過洗掉檔案來洗掉表，這要快得多，洗掉表并不是常見的操作，SQLite花費的時間稍長，也不是大問題，

測驗內容

  • 空資料庫場景
  • 業務場景：資料庫大小在26G左右，參見性能測驗方案的資料模型部分，
  • 性能測驗場景：在執行性能、負載、尖峰、壓力等測驗時通過API或命令列執行，

測驗代碼

以下代碼使用python呼叫sqlite庫實作測驗，同時將sql匯出為sql檔案，以方便命令列執行，后續需要支持呼叫我司DB的python API，
代碼最新版本存放在https://github.com/china-testing/python-testing-examples/blob/master/db/sqlite_speed.py

import random
import time

from num2word import word
import sqlite3


def open_database():
    
    db = 'pydb.db'
    conn = sqlite3.connect(db)
    return conn

def get_conn_and_cursor(name, sql=''):
    
    print("*"*20, name)
    conn = open_database()
    cursor = conn.cursor()
    if sql:
        cursor.execute(sql)
        conn.commit();    
    return conn, cursor

def list2file(lists, filename):
    
    f = open(filename, 'w')
    for item in lists:
        f.write(item + "\n")
    f.close()
    

def insert_1000():
    
    sqls = []
    sql = ''' DROP TABLE IF EXISTS t1;'''
    sqls.append(sql)
    conn, cursor = get_conn_and_cursor("Test 1: 1000 INSERTs", sql)
    
    t1 = time.time()   
    sql = ''' CREATE TABLE t1(a INTEGER, b INTEGER, c VARCHAR(100));'''
    cursor.execute(sql)
    conn.commit()
    for i in range(1, 1001):
        num = random.randint(1, 100000000)
        num_str = word(num).lower()
        sql = '''INSERT INTO t1 VALUES({}, {},'{}');'''.format(i, num, num_str)
        cursor.execute(sql)
        sqls.append(sql)
        conn.commit()    
    print("*"*10, time.time()-t1)
    list2file(sqls, "1.sql")
    conn.close()
    
def insert_25000_transaction():
    
    sqls = []
    sql = '''DROP TABLE IF EXISTS t2;'''
    sqls.append(sql)
    conn, cursor = get_conn_and_cursor("Test 2: 25000 INSERTs in a transaction", sql)
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    sql = ''' CREATE TABLE t2(a INTEGER, b INTEGER, c VARCHAR(100));'''
    sqls.append(sql)
    cursor.execute(sql)
    for i in range(1, 25001):
        num = random.randint(1, 100000000)
        num_str = word(num).lower()
        sql = '''INSERT INTO t2 VALUES({}, {},'{}');'''.format(i, num, num_str)
        sqls.append(sql)
        cursor.execute(sql)
    conn.commit()  
    sqls.append("COMMIT;")
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "2.sql")
    
def insert_25000_transaction_index():
    
    sqls = []
    sql = '''DROP TABLE IF EXISTS t3;'''
    sqls.append(sql)
    conn, cursor = get_conn_and_cursor("Test 3: 25000 INSERTs into an indexed table", sql)    
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    sql = ''' CREATE TABLE t3(a INTEGER, b INTEGER, c VARCHAR(100));'''
    sqls.append(sql)
    cursor.execute(sql)
    sql = '''CREATE INDEX i3 ON t3(c);'''
    sqls.append(sql)
    cursor.execute(sql)    
    for i in range(1, 25001):
        num = random.randint(1, 100000000)
        num_str = word(num).lower()
        sql = '''INSERT INTO t1 VALUES({}, {},'{}');'''.format(i, num, num_str)
        sqls.append(sql)
        cursor.execute(sql)
    conn.commit()  
    sqls.append("COMMIT;")
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "3.sql")
    
    
def select_100_without_index():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 4: 100 SELECTs without an index")        
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    for i in range(100):
        sql = '''SELECT count(*), avg(b) FROM t2 WHERE b>={} AND b<{};'''.format(i*100, i*100+1000)
        sqls.append(sql)
        cursor.execute(sql)
    conn.commit() 
    sqls.append("COMMIT;")
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "4.sql")
    

def select_100_comparison():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 5: 100 SELECTs on a string comparison")
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    for i in range(1,101):
        sql = '''SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%{}%';'''.format(word(i).lower())
        sqls.append(sql)
        cursor.execute(sql)
    conn.commit() 
    sqls.append("COMMIT;")
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "5.sql")
    
def create_index():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 6: Creating an index")
 
    t1 = time.time()   
    sql = ''' CREATE INDEX i2a ON t2(a);'''
    sqls.append(sql)
    cursor.execute(sql)   
    conn.commit() 
    sql = ''' CREATE INDEX i2b ON t2(b); '''
    sqls.append(sql)
    cursor.execute(sql)   
    conn.commit() 
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "6.sql")
    
def select_5000_with_index():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 7: 5000 SELECTs with an index")
 
    t1 = time.time()   
    for i in range(5000):
        sql = '''SELECT count(*), avg(b) FROM t2 WHERE b>={} AND b<{};'''.format(i*100, i*100+100)
        sqls.append(sql)
        cursor.execute(sql)
        conn.commit()    
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "7.sql")


def update_1000_without_index():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 8: 1000 UPDATEs without an index")
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    for i in range(1000):
        sql = '''UPDATE t1 SET b=b*2 WHERE a>={} AND a<{};'''.format(i*10, i*10+10)
        sqls.append(sql)
        cursor.execute(sql)
    conn.commit()   
    sqls.append("COMMIT;")
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "8.sql")
    
def update_25000_with_index():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 9: 25000 UPDATEs with an index")
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    for i in range(25000):
        sql = '''UPDATE t2 SET b={} WHERE a={};'''.format(random.randint(1, 100000000), i+1)
        sqls.append(sql)
        cursor.execute(sql)
    conn.commit()   
    sqls.append("COMMIT;")
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "9.sql")
    
def update_25000_text_with_index():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 10: 25000 text UPDATEs with an index")
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    for i in range(25000):
        sql = '''UPDATE t2 SET c='{}' WHERE a={};'''.format(word(random.randint(1, 100000000)).lower(), i+1)
        cursor.execute(sql)
        sqls.append(sql)
    conn.commit()  
    sqls.append("COMMIT;")
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "10.sql")

def insert_from_select():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 11: INSERTs from a SELECT")
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    sql = '''INSERT INTO t1 SELECT b,a,c FROM t2;'''
    sqls.append(sql)
    cursor.execute(sql)
    sql = '''INSERT INTO t2 SELECT b,a,c FROM t1;'''
    sqls.append(sql)
    cursor.execute(sql)  
    conn.commit() 
    sqls.append("COMMIT;")
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "11.sql")
    

def del_without_index():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 12: DELETE without an index")
 
    t1 = time.time()   
    sql = '''DELETE FROM t2 WHERE c LIKE '%fifty%'; '''
    sqls.append(sql)
    cursor.execute(sql)  
    conn.commit() 
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "12.sql")
    
def del_with_index():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 13: DELETE with an index")
 
    t1 = time.time()   
    sql = '''DELETE FROM t2 WHERE a>10 AND a<20000;  '''
    sqls.append(sql)
    cursor.execute(sql)  
    conn.commit() 
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "13.sql")
    
def big_insert_after_big_del():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 14: A big INSERT after a big DELETE")
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    sql = '''DELETE FROM t2;'''
    sqls.append(sql)
    cursor.execute(sql)
    sql = '''INSERT INTO t2 SELECT * FROM t1; '''
    sqls.append(sql)
    cursor.execute(sql)  
    conn.commit()
    sqls.append("COMMIT;")
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "14.sql")


def small_insert_after_big_del():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 15: A big DELETE followed by many small INSERTs")
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    sql = '''DELETE FROM t1;'''
    sqls.append(sql)
    cursor.execute(sql)
    for i in range(1, 12001):
        num = random.randint(1, 100000000)
        num_str = word(num).lower()
        sql = '''INSERT INTO t1 VALUES({}, {},'{}');'''.format(i, num, num_str)
        sqls.append(sql)
        cursor.execute(sql)
    conn.commit() 
    sqls.append("COMMIT;")
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "15.sql")
    
def drop_table():
    
    sqls = []
    conn, cursor = get_conn_and_cursor("Test 16: DROP TABLE")
 
    t1 = time.time()   
    cursor.execute("BEGIN")
    sqls.append("BEGIN;")
    sql = '''DROP TABLE t1;'''
    sqls.append(sql)
    cursor.execute(sql)
    conn.commit() 
    sql = '''DROP TABLE t2;'''
    sqls.append(sql)
    cursor.execute(sql)
    conn.commit() 
    sql = '''DROP TABLE t3;'''
    sqls.append(sql)
    cursor.execute(sql)
    conn.commit() 
    print("*"*10, time.time()-t1)
    conn.close()
    list2file(sqls, "16.sql")
    
insert_1000()
insert_25000_transaction()
insert_25000_transaction_index()
select_100_without_index()
select_100_comparison()
create_index()
select_5000_with_index()
update_1000_without_index()
update_25000_with_index()
update_25000_text_with_index()
insert_from_select()
del_without_index()
del_with_index()
big_insert_after_big_del()
small_insert_after_big_del()
drop_table()
釘釘或微信號: pythontesting 微信公眾號：pythontesting

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/556074.html

標籤：其它

上一篇：檔案室溫度和濕度控制標準及防控措施技術性八防方案

下一篇：返回列表

標籤雲
其他(161684) Python(38254) JavaScript(25515) Java(18265) C(15238) 區塊鏈(8273) C＃(7972) AI(7469) 爪哇(7425) MySQL(7270) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5875) 数组(5741) R(5409) Linux(5347) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4606) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2437) ASP.NET(2404) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) .NET技术(1985) HtmlCss(1973) 功能(1967) Web開發(1951) C++(1942) python-3.x(1918) 弹簧靴(1913) xml(1889) PostgreSQL(1881) .NETCore(1863) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀：**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題，由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視，實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶，一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀：**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高，采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐，遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀：**滴滴資料通道引擎承載著全公司的資料同步，為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加，資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程，遇到的問題以及今后的規劃。 #1. 背景 資料，對于任何一家互聯網公司來說都是非常重要的資產，公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀：**深耕人工智能領域，致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎，這次獲獎的專案是什么呢？一起來看看詳細報道吧！ 近日，由國際計算語言學協會ACL（The Association for Computational Linguistics）舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp？ MPP (Massively Parallel Processing)，即大規模并行處理，在資料庫非共享集群中，每個節點都有獨立的磁盤存盤系統和記憶體系統，業務資料根據資料庫模型和應用特點劃分到各個節點上，每臺資料節點通過專用網路或者商業通用網路互相連接，彼此協同計算，作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀：**指標體系是什么？如何使用OSM模型和AARRR模型搭建指標體系？如何統一流程、規范化、工具化管理指標體系？本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標，系統化的組織起來，通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索，LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料，可以使用下面的 SQL 陳述句： SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀：**Ceph是國際知名的開源分布式存盤系統，在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統， ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章，這一次主要寫一個嵌套的聚合，例如先對sex集合，再對desc聚合，最后再對age求和，共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by，avg，sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack（ELK）部署

    傻瓜式部署，只需替換IP與用戶 導讀： 現ELK四大組件分別為：Elasticsearch（核心）、logstash（處理）、filebeat（采集）、kibana（可視化） 下載均在https://www.elastic.co/cn/downloads/下tar包，各組件版本最好一致，配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • 關系型資料庫速度比較(性能基準測驗)及python實作

    https://www.sqlite.org/speed.html 做了SQLite、MySQL和PostgreSQL的速度比較，使用的資料庫版本比較老，但是測驗方法依舊頗有意義。 ![](https://img2023.cnblogs.com/blog/3174021/202306/3174021 ......

    uj5u.com 2023-06-27 09:13:23 more
  • 檔案室溫度和濕度控制標準及防控措施技術性八防方案

    檔案館庫房溫濕度調控標準及相應的措施方案 檔案庫房是檔案保管的基本條件，檔案庫房溫濕度與保護檔案，延長檔案壽命有很大關系。 檔案庫房適宜溫濕度標準為：溫度14℃—24℃，相對濕度45％一60 一、庫房溫濕度對檔案的影響 庫房的溫濕度，過高過低都會影響檔案制成材料的耐久性。高溫高濕會加速紙張的老化水解 ......

    uj5u.com 2023-06-27 09:13:16 more
  • 一招帶你吃透MySQL高級

    `MySQL8高級之架構和優化` 讓 ![img](https://image-tuchuang.oss-cn-chengdu.aliyuncs.com/timg.jpg) # 第01章 Linux下MySQL的安裝與使用 ## 1、安裝 ### 1.1、docker安裝 ```shell dock ......

    uj5u.com 2023-06-27 09:05:31 more
  • 教程 | Datavines 自定義資料質量檢查規則（Metric）

    Metric 是 Datavines 中一個核心概念，一個 Metric 表示一個資料質量檢查規則，比如空值檢查和表行數檢查都是一個規則。Metric 采用插件化設計，用戶可以根據自己的需求來實作一個 Metric。下面我們來詳細講解一下如何自定義`Metric`。 ### 第一步 我們先了解下幾個 ......

    uj5u.com 2023-06-27 09:03:28 more
  • Spark架構體系

    # Spark架構體系 StandAlone模式是spark自帶的集群運行模式，不依賴其他的資源調度框架，部署起來簡單。 StandAlone模式又分為client模式和cluster模式，本質區別是Driver運行在哪里，如果Driver運行在SparkSubmit行程中就是Client模式，如果 ......

    uj5u.com 2023-06-27 08:58:06 more
  • 日均調度 10W+ 任務實體，DolphinScheduler 在蔚來汽車一站式資料

    ![file](https://img2023.cnblogs.com/other/2685289/202306/2685289-20230626191342850-513894679.png) 大家好我是張金明，在蔚來汽車擔任大資料平臺研發工程師。這次和大家分享的是 Apache DolphinS ......

    uj5u.com 2023-06-27 08:47:34 more
  • 圖書搜索領域重大突破！用Apache SeaTunnel、Milvus和OpenAI提高書

    ![file](https://img2023.cnblogs.com/other/3195851/202306/3195851-20230626190205684-2107268424.jpg) 作者 | 劉廣東，Apache SeaTunnel Committer ## 背景 目前，現有的圖書搜 ......

    uj5u.com 2023-06-27 08:42:14 more
  • Spark簡介

    # Spark Spark是一種快速、通用、可擴展的大資料分析引擎，2009年誕生于加州大學伯克利分校AMPLab，2010年開源，2013年6月成為Apache范訓專案，2014年2月成為Apache的頂級專案，2014年5月發布spark1.0，2016年7月發布spark2.0，2020年6月 ......

    uj5u.com 2023-06-26 09:35:16 more
  • SeaTunnel 發布成為 Apache 頂級專案后首個版本 2.3.2，進一步提高

    ![file](https://img2023.cnblogs.com/other/3195851/202306/3195851-20230625185718639-2144905227.jpg) > 近日，Apache SeaTunnel 正式發布 2.3.2 版本。此時距離上一版本 2.3.1 ......

    uj5u.com 2023-06-26 09:35:09 more
  • 構建高可用性的 SQL Server：Docker 容器下的主從同步實作

    摘要：本文將介紹如何在 Docker 環境下搭建 MS SQL Server 的主從同步，幫助讀者了解主從同步的原理和實作方式，進而提高資料的可靠性和穩定性。 一、前言 在當今資訊化的時代，資料的安全性和穩定性顯得尤為重要。資料庫是許多企業和組織存盤和管理資料的核心，因此如何保證資料庫的高可用性和數 ......

    uj5u.com 2023-06-26 09:35:00 more

Copyright © 2010-2020 有解無憂