MySQL字元函式的壓力測試

MySQL中的字串處理函式非常多，以至於我在整理的這部分內容的時候也眼前一亮，有一種進了大觀園的感覺，哦，原來有這個函式，哦，竟然可以這樣實現，以前怎麼沒想到，等等。

比如字串查詢函式，instr,locate,position三個函式的功能都是很相似的。如果要實現一個功能，從字串foobarbar裡面找到bar這個字串的起始位置，使用Instr,locate,position都可以實現。

SELECT INSTR('foobarbar', 'bar');

SELECT LOCATE('bar', 'foobarbar');

SELECT POSITION('bar' IN 'foobarbar');

主要語法的表現形式不同，當然引數設定上還是有一些差別。

對於上面的3個函式，我有些糾結，到底用哪一個呢？推薦是哪一個呢?我覺得可以透過兩種測試方式來得到一個初步的結論，第一個是高併發下多執行緒呼叫的效能情況，第二個是單執行緒執行的效能情況。如果在對比測試中高出一籌，還有什麼理由不去推薦呢。

要實現這兩個功能，MySQL缺失提供了這樣的工具集，第一個是併發執行的效能情況，可以使用MySQL自帶的mysqlslap來測試。

而第二個單執行緒的壓測，則可以使用MySQL非常有特色的函式benchmark來實現。

如果使用myslap來壓測，使用mysqlslap的語句類似下面的形式。

mysqlslap --concurrency=50,100 --create-schema="test" --query="SELECT POSITION('bar' in 'foobar');" --number-of-queries=50000

當然這裡我們加大難度，一個是拼接的字串要複雜，我們可以使用字串函式repeat得到一個很長的字串，比如concat(concat(repeat('abc',500),'foobarbar'),repeat('abc',500)) 就可以得到一個很長的字串。

透過這種方式得到的測試結果相對來說更有意義一些。

我們調大呼叫的頻次為100萬次，使用併發50和100來做測試。

position函式的結果

Benchmark

Average number of seconds to run all queries: 34.789seconds

Minimum number of seconds to run all queries: 34.789 seconds

Maximum number of seconds to run all queries: 34.789 seconds

Number of clients running queries: 50

Average number of queries per client: 20000

Benchmark

Average number of seconds to run all queries: 35.312 seconds

Minimum number of seconds to run all queries: 35.312 seconds

Maximum number of seconds to run all queries: 35.312 seconds

Number of clients running queries: 100

Average number of queries per client: 10000

可以看出在併發50和100的情況下，100的呼叫時間略長。

使用locate和Instr得到的結果相仿，都是36秒~37秒之間。

從100萬次的測試中我們可以得到一個初步udev結論，那就是在這個場景中，position的效能相當要好一些。

而單執行緒的壓測情況如何呢，我們使用benchmark來模擬。

比如壓測md5的函式，就是這樣的格式。

select benchmark( 500000000, md5( 'test' ) );

對於position和locate,instr，只是需要調整一下函式就可以了，我們還是指定為100萬次。

position,locate,instr的效能結果是

1 row in set (8.23 sec)

1 row in set (8.21 sec)

1 row in set (8.23 sec)

可以看出來效能幾乎是一樣的，locate略微高一點點。

從這個測試也可以看出明顯的效能差別，單執行緒壓測的時候是8秒多，但是併發的時候就是36秒左右，這個差別其實很大了。