IT序号网

mysql之SQL表拆分-有必要吗

insus 2024年08月12日 编程语言 16 0

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

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

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

简而言之,我的问题是如果我拆分表,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。这是可行的还是应该将它们拆分为多个表以减少查询执行时间

请您参考如下方法:

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

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

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

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


    评论关闭
    IT序号网

    微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!