C sqlite中的表名长度会影响性能。为什么？

我注意到，在创建这些表的过程中，表名的长度会影响性能。下面是重现问题的代码示例：

#include <stdio.h>
#include <assert.h>
#include "sqlite3.h"

int main() {
  int i, sr;
  char table_query[1000];
  sqlite3* db;

  sr = sqlite3_open("test.db", &db);
  assert(sr == SQLITE_OK);

  sr = sqlite3_exec(db, "PRAGMA synchronous=OFF", NULL, NULL, NULL);
  assert(sr == SQLITE_OK);

  sr = sqlite3_exec(db, "PRAGMA journal_mode=OFF", NULL, NULL, NULL);
  assert(sr == SQLITE_OK);

  sr = sqlite3_exec(db, "PRAGMA temp_store=MEMORY", NULL, NULL, NULL);
  assert(sr == SQLITE_OK);

  sr = sqlite3_exec(db, "BEGIN EXCLUSIVE TRANSACTION;", NULL, NULL, NULL);
  assert(sr == SQLITE_OK);

  for (i = 0; i < 10000; ++i) {
  #ifdef LONG_NAMES
   sprintf(table_query, "CREATE TABLE `TABLE_%d_AKLKEKABCDEFGHIJK4C6F766520416C6C20546865205061696E204177617920496E636C204B796175202620416C626572742052656D69782020434452` (content);", i);
  #else
   sprintf(table_query, "CREATE TABLE `TABLE_%d` (content);", i);
  #endif

   sr = sqlite3_exec(db, table_query, NULL, NULL, NULL);
   assert(sr == SQLITE_OK);

  }

  sr = sqlite3_exec(db, "END TRANSACTION;", NULL, NULL, NULL);
  assert(sr == SQLITE_OK);

  sr = sqlite3_close(db);
  assert(sr == SQLITE_OK);

  return 0;
}

#包括
#include似乎认为MySQL的答案是“不”，但没有给出任何参考

想法

注意：我使用的是最新合并版本的sqlite（3.8）
较长的表名在
sqlite\u master
系统表中占用更多的空间（比较文件大小）。
当SQLite遍历该系统表以搜索该表（或检查新表名是否已存在）时，需要读取和比较更多数据

但是，在查询时，SQLite仅在第一次实际访问架构时才从系统表加载数据，因此查询性能不会受到太大影响。
对于较长的表名，生成的空数据库文件要大4倍，因为较长的表名会占用架构中更多的空间。毫不奇怪，SQLite要花费4倍的时间来编写4倍的内容

请注意，表名只存储一次。因此，一旦开始向数据库添加内容，两者之间的相对大小差异将减小，逐渐接近1.0。两个数据库之间大小的绝对差异应保持不变。
具有120个字符名称的10000个表是实际用例吗？@CL-Yes。这是一个实际的用例。虽然可以将所有这些数据放在一个表中，但这会使我的实现的其他方面变得非常复杂。我想了解一下，在放弃并转向更平坦的数据库设计之前，是否可以做些什么来解决这个表名性能问题。FWIW，我必须在RedHat 6.4和GCC 4.4.7上添加-pthread-ldl，以正确地链接这个示例和SQLite 3.8.0.2。对于较短的名称，创建11MB的test.db需要10.7s（3次运行），而创建添加了-DLONG_名称的15MB test.db需要27.5s（也需要3次运行）。“SQLite需要4倍的时间来编写4倍的内容，这并不奇怪。”-我不确定我是否同意这一说法。如果我将数据库设计为使用单个表并将表名描述为行，则创建数据库的速度要快得多。快一个数量级。我所描述的性能问题特别与创建表有关。行中较长的条目不会像较长的表名那样影响性能。