【问题标题】:SQL Table Split-Is it necessarySQL表拆分-有必要吗
【发布时间】:2012-02-13 09:39:49
【问题描述】:

我有一个包含大约 6-7lacs 记录的表,并且随着时间的推移它会增长。它有大约 16-20 列。与这些列中的任何一个都没有一对多关系。

用户数据条目存储在这些表中。

那么将我的表拆分为多个小表是否可行,或者只是将表拆分为两半,其中包含所有条目以及其他最近的新记录,这些记录将呈现给数据输入操作员以供输入他们的条目。

简而言之,我的问题是如果我拆分表,mysql 执行时间是否会更快,或者如果我将它们分成两半会更快。

我猜后者会更可行,因为它不会执行任何连接查询。

更新:

CREATE TABLE `images` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `primary_category_id` int(10) unsigned DEFAULT NULL,
  `secondary_category_id` int(10) unsigned DEFAULT NULL,
  `front_url` varchar(255) DEFAULT NULL,
  `back_url` varchar(255) DEFAULT NULL,
  `title` varchar(100) DEFAULT NULL,
  `part` varchar(10) DEFAULT NULL,
  `photo_id` int(10) unsigned DEFAULT NULL,
  `photo_dt_month` varchar(2) DEFAULT NULL,
  `photo_dt_day` varchar(2) DEFAULT NULL,
  `photo_dt_yr` varchar(4) DEFAULT NULL,
  `type` varchar(25) DEFAULT NULL,
  `size_width` int(10) unsigned DEFAULT NULL,
  `size_height` int(10) unsigned DEFAULT NULL,
  `dpi` int(10) unsigned NOT NULL DEFAULT '0',
  `dpix` int(10) unsigned DEFAULT NULL,
  `dpiy` int(10) unsigned DEFAULT NULL,
  `in_stock` varchar(50) DEFAULT NULL,
  `outlet` varchar(50) DEFAULT NULL,
  `source` varchar(50) DEFAULT NULL,
  `keywords` varchar(255) DEFAULT NULL,
  `emotional_keywords` varchar(255) DEFAULT NULL,
  `mechanical_keywords` varchar(255) DEFAULT NULL,
  `description` text,
  `notes` text,
  `comments` text,
  `exported_to_ebay_dt` datetime DEFAULT NULL,
  `exported_to_ebay` set('Y','N') NOT NULL DEFAULT 'N',
  `updated_worker_id` int(10) unsigned DEFAULT NULL,
  `updated_worker_dt` datetime DEFAULT NULL,
  `locked_worker_id` int(10) unsigned DEFAULT NULL,
  `locked_worker_dt` datetime DEFAULT NULL,
  `updated_admin_id` int(10) unsigned DEFAULT NULL,
  `updated_admin_dt` datetime DEFAULT NULL,
  `added_dt` datetime DEFAULT NULL,
  `updated_manager_id` int(10) unsigned DEFAULT NULL,
  `updated_manager_dt` datetime DEFAULT NULL,
  `manager_review` set('Y','N') NOT NULL DEFAULT 'N',
  `paid_status` set('Y','N') NOT NULL DEFAULT 'N',
  `exported_to_web_dt` datetime DEFAULT NULL,
  `exported_to_web` set('Y','N') DEFAULT 'N',
  `prefix` varchar(50) DEFAULT NULL,
  `is_premium` set('Y','N') DEFAULT 'N',
  `template` varchar(50) DEFAULT 'HIPE_default',
  `photographer` varchar(100) DEFAULT NULL,
  `copyright` varchar(100) DEFAULT NULL,
  `priority` int(4) DEFAULT '1',
  `step` set('1','2') DEFAULT '1',
  PRIMARY KEY (`id`),
  UNIQUE KEY `part` (`part`),
  KEY `primary_category_id` (`primary_category_id`),
  KEY `updated_worker_id` (`updated_worker_id`),
  KEY `updated_worker_dt` (`updated_worker_dt`)
) ENGINE=MyISAM AUTO_INCREMENT=1013687 DEFAULT CHARSET=latin1

以上是我的表结构。在 1lac 左右创建条目后,我会将其拆分为另一个表,例如具有相同结构的 images_history。这是可行的还是应该将它们拆分为多个表以减少查询执行时间

【问题讨论】:

  • 您能否添加一些 DDL,大致描述您的表格的外观以及拆分后的外观?
  • 感谢编辑...不知道为什么没有格式化
  • 对于那些不熟悉亚洲数字的人来说,10 万 = 100'000

标签: mysql sql-execution-plan


【解决方案1】:

为什么要拆分表?如果您仍想访问这两个新表,这将导致大量额外代码并通过添加额外查询来减慢执行时间。 (如果其中一个表要存储很少使用的以前版本的图像表记录 - 即版本控制 - 它可能仍然是一个好主意)。

在考虑拆分表之前,看看是否可以通过优化现有代码来提高性能,确保以下性能灾难都不存在:

  • 是否所有 SELECT 都按 PRIMARY KEY 过滤?
  • 索引缓存是否足够大以容纳计算机 RAM 中的所有索引?
  • 是否有任何字符串使用索引匹配带有 LIKE 的 SELECT? IE。只有完全匹配或通配符在右边,从不在左边(例如“searchword%”,从不“%searchword”
  • 是否存在使用 SELECT * 而不是仅选择您需要的列的执行缓慢的查询?
  • 您是否避免在 SELECT 中使用 OR?

如果表被正确索引并且查询实际上正在使用这些索引,则对具有 700 000 条记录的表执行查询应该不会很慢。

【讨论】:

  • 是的,通过索引可以提高性能,但是如果我将包含大约 15-20 列的表划分为 3-4 个表,每个表有 5-6 列并具有良好的索引。这样做会减少我的 sql 执行时间吗?这是我真正的问题
  • 如果您有一个 BLOB 类型(TEXT、LONGTEXT)的列,SELECT * 或 SELECT blobcolumn 将强制将数据写入磁盘上的 TMP 表而不是 RAM。如果您通过使用索引列实际访问您实际要使用的列,那么拥有大量列将不会减慢任何速度。
  • @Harald:谢谢!我没有很多文本列,只有 2-3 个(检查我上面的结构)。如果我运行诸如 Select * 之类的查询并且我只有几列上的索引,那么查询执行时间会增加。是拆分表那么有必要吗?
猜你喜欢
  • 1970-01-01
  • 2021-03-04
  • 2021-11-11
  • 1970-01-01
  • 2016-10-03
  • 2012-12-14
  • 2018-02-28
  • 1970-01-01
  • 2016-04-24
相关资源
最近更新 更多