Performance Comparison of ScaleFlux CSD 2000 vs Intel SSD for MySQL Workloads

This translated article reports on a performance benchmark conducted by Percona engineers comparing ScaleFlux CSD 2000 storage with Intel SSDs for MySQL workloads.

Why ScaleFlux? It provides built‑in compression and atomic‑write support, which are valuable for database workloads that can benefit from reduced storage footprint and higher reliability.

Test environment

Storage devices:
ScaleFlux – CSD 2000 4TB
Intel – P4610 3.2TB

Application server: Supermicro SYS-6019U-TN4RT
48× Intel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz
190G RAM

Database server: Inspur SA5212M4
32× Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
64G RAM

Sysbench was run on the application server while Percona Server for MySQL 8.0.19 ran on the database server. Binary logging, slow‑query logging, and adaptive hash indexing were disabled; both double‑write enabled and disabled configurations were tested.

innodb_buffer_pool_size=8G
innodb_log_file_size=2G
max_connections=500
slow_query_log=off
disable_log_bin
innodb_doublewrite=ON/OFF
tmpdir=/var/lib/mysql/
innodb_adaptive_hash_index=off
innodb_flush_method=O_DIRECT
innodb_purge_threads=32
sync_binlog=0
max_prepared_stmt_count=4000000

Tests performed

Standard OLTP read‑only, write‑only, and read‑write workloads.

Modified schema adding two VARCHAR columns (data1, data2) to evaluate compression benefits.

Custom Lua scripts for sysbench to adjust table count and data size.

CREATE TABLE `sbtest1` (
  `id` int NOT NULL AUTO_INCREMENT,
  `k` int NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  `data1` varchar(255) DEFAULT NULL,
  `data2` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `k_1` (`k`),
  KEY `idx_data1` (`data1`)
) ENGINE=InnoDB AUTO_INCREMENT=9999948 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

index_updates = {
      "UPDATE %s%u SET k=?,data1=? WHERE id=?",
      t.INT,{t.CHAR,255},t.INT},

   non_index_updates = {
      "UPDATE %s%u SET c=?,data2=? WHERE id=?",
       {t.CHAR,120},{t.CHAR,255},t.INT},

   inserts = {
      "INSERT INTO %s%u (id, k, c, pad, data1, data2) VALUES (?, ?, ?, ?, ?, ?)",
      t.INT, t.INT, {t.CHAR, 120}, {t.CHAR, 60}, {t.CHAR,255}, {t.CHAR,255}},

   index_selects = {
      "SELECT id,data2 FROM %s%u WHERE data1=?",
      {t.CHAR,255}},

   update_based_on_data1 = {
      "UPDATE %s%u SET data2=? WHERE data1=?",
       {t.CHAR,255},{t.CHAR,255}},

The benchmark scenarios included:

Default sysbench – 100 tables, 1 M rows each (≈220 GB).

Modified sysbench – 100 tables, 1 M rows each with extra columns (≈440 GB).

Large‑scale runs up to 2.5 TB data size across 540 tables.

Key results

In the default 220 GB test, Intel SSD slightly outperformed ScaleFlux at low concurrency, but ScaleFlux took the lead after ~96 concurrent threads.

When compression‑friendly data (440 GB) was used, ScaleFlux showed a clear performance advantage, especially under high concurrency.

With both devices running with InnoDB double‑write disabled, ScaleFlux consistently delivered higher throughput and lower latency.

ScaleFlux exhibited lower iowait (≈11 %) compared to Intel SSD (≈32 %).

IOPS on ScaleFlux were roughly double those of Intel SSD, translating to higher MySQL QPS/TPS.

Disk latency remained stable on ScaleFlux, while Intel SSD showed larger variance.

CPU usage graphs confirmed that ScaleFlux maintained better efficiency under the heaviest workloads.

Conclusion

The tests confirm that ScaleFlux storage delivers genuine performance benefits for MySQL when the workload involves large, compressible data sets; the built‑in compression and atomic‑write features provide up to twice the write performance of comparable Intel SSDs. For smaller, non‑compressible data sets, Intel SSDs may still be cost‑effective.