简体   繁体   English

MySQL 连接查询耗时太长

[英]MySQL join query taking far too long

The following query is taking forever in MySQL 5.7.23, on a macOS 10.13.6 on 2018 Macbook Pro (A1990) with 50GB of free space:以下查询在 MySQL 5.7.23 和 2018 Macbook Pro (A1990) 上的 macOS 10.13.6 中永久占用 50GB 可用空间:

INSERT INTO `a_sg1lib` (`book_id`,`title`, `isbn`, `Zstatus_retrieve_TOC`, `Zstatus_retrieve_classifybyoclc`, 
`classifybyoclc_respcode`, `classifybyoclc_calln_lcc`, `classifybyoclc_calln_ddc`, `classifybyoclc_calln_nlm`, 
`classifybyoclc_fast`, `classifybyoclc_owi`,`reference`, `data`, `crcomment`, `groupname`, `code`, `indentation`, `path`, `specialtag`, 
`specialtag_cat`, `specialtag_master`, `specialtag_master_cat`, `specialtag_override_cat_moddetails`, 
`specialtag_override_cat_timestamp`, `specialtag_override_cat`, `pageno`, `specialtag_escalated`, `history`, 
`history_classification`, `specialtag_esc_start`, `specialtag_esc_start_type`, `callCore`, 
`d1`, `d2`, `d3`, `d4`, `d5`, `d6`, `d7`, `d8`, `d9`, `d10`, `d11`, `d12`) 
SELECT `RU_sg1lib_classifybyoclc`.`ID`,`Title`, `IdentifierWODash`, `Zstatus_retrieve_TOC`, `Zstatus_retrieve_classifybyoclc`, `classifybyoclc_respcode`, `classifybyoclc_calln_lcc`, 
    `classifybyoclc_calln_ddc`, `classifybyoclc_calln_nlm`, 
    `classifybyoclc_fast`, `classifybyoclc_owi`,`reference`, `data`,
    `crcomment`, `groupname`, `code`, `indentation`, `path`, `specialtag`, `specialtag_cat`, 
    `specialtag_master`, `specialtag_master_cat`, `specialtag_override_cat_moddetails`, 
    `specialtag_override_cat_timestamp`, `specialtag_override_cat`, `pageno`, `specialtag_escalated`, `history`, 
    `history_classification`, `specialtag_esc_start`, `specialtag_esc_start_type`, `callCore`, 
    `d1`, `d2`, `d3`, `d4`, `d5`, `d6`, `d7`, `d8`, `d9`, `d10`, `d11`, `d12` 
FROM `RU_sg1lib_classifybyoclc` 
RIGHT JOIN `loc_classification`.`LOC_Classification_Text_zFULL_YYY`
   ON `RU_sg1lib_classifybyoclc`.`classifybyoclc_calln_lcc`=
      `loc_classification`.`LOC_Classification_Text_zFULL_YYY`.`callCore`;

Number of rows:行数:

RU_sg1lib_classifybyoclc - 1+ million rows - MyISAM RU_sg1lib_classifybyoclc - 1+ 百万行 - MyISAM

LOC_Classification_Text_zFULL_YYY - 440000+ rows - InnoDB LOC_Classification_Text_zFULL_YYY - 440000+ 行 - InnoDB

a_sg1lib - InnoDB, initially empty a_sg1lib - InnoDB,最初为空

Schema:架构:

 CREATE TABLE `RU_sg1lib_classifybyoclc` (
  `ID` int(15) unsigned NOT NULL AUTO_INCREMENT,
  `Title` varchar(2000) DEFAULT '',
  `VolumeInfo` varchar(100) DEFAULT '',
  `Series` varchar(300) DEFAULT '',
  `Periodical` varchar(200) DEFAULT '',
  `Author` varchar(1000) DEFAULT '',
  `Year` varchar(14) DEFAULT '',
  `Edition` varchar(60) DEFAULT '',
  `Publisher` varchar(400) DEFAULT '',
  `City` varchar(100) DEFAULT '',
  `Pages` varchar(100) DEFAULT '',
  `PagesInFile` int(10) unsigned NOT NULL DEFAULT '0',
  `Language` varchar(150) DEFAULT '',
  `Topic` varchar(500) DEFAULT '',
  `Library` varchar(50) DEFAULT '',
  `Issue` varchar(100) DEFAULT '',
  `Identifier` varchar(300) DEFAULT '',
  `ISSN` varchar(9) DEFAULT '',
  `ASIN` varchar(200) DEFAULT '',
  `UDC` varchar(200) DEFAULT '',
  `LBC` varchar(200) DEFAULT '',
  `DDC` varchar(45) DEFAULT '',
  `LCC` varchar(45) DEFAULT '',
  `Doi` varchar(45) DEFAULT '',
  `Googlebookid` varchar(45) DEFAULT '',
  `OpenLibraryID` varchar(200) DEFAULT '',
  `Commentary` varchar(10000) DEFAULT '',
  `DPI` int(6) unsigned DEFAULT '0',
  `Color` varchar(1) DEFAULT '',
  `Cleaned` varchar(1) DEFAULT '',
  `Orientation` varchar(1) DEFAULT '',
  `Paginated` varchar(1) DEFAULT '',
  `Scanned` varchar(1) DEFAULT '',
  `Bookmarked` varchar(1) DEFAULT '',
  `Searchable` varchar(1) DEFAULT '',
  `Filesize` bigint(20) unsigned NOT NULL DEFAULT '0',
  `Extension` varchar(50) DEFAULT '',
  `MD5` char(32) DEFAULT '',
  `Generic` char(32) DEFAULT '',
  `Visible` char(3) DEFAULT '',
  `Locator` varchar(733) DEFAULT '',
  `Local` int(10) unsigned DEFAULT '0',
  `TimeAdded` timestamp NOT NULL DEFAULT '2000-01-01 13:00:00',
  `TimeLastModified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `Coverurl` varchar(200) DEFAULT '',
  `Tags` varchar(500) DEFAULT '',
  `IdentifierWODash` varchar(300) DEFAULT '',
  `Zstatus_retrieve_TOC` varchar(255) DEFAULT NULL,
  `Zstatus_retrieve_classifybyoclc` varchar(255) DEFAULT NULL,
  `classifybyoclc_respcode` text,
  `classifybyoclc_calln_lcc` varchar(256) DEFAULT NULL,
  `classifybyoclc_calln_ddc` text,
  `classifybyoclc_calln_nlm` text,
  `classifybyoclc_fast` text,
  `classifybyoclc_owi` text,
  `classifybyoclc_timest` text,
  `pid` text,
  `ida` int(11) DEFAULT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `MD5` (`MD5`),
  KEY `Generic` (`Generic`) USING BTREE,
  KEY `VisibleTimeAdded` (`Visible`,`TimeAdded`) USING BTREE,
  KEY `TimeAdded` (`TimeAdded`) USING BTREE,
  KEY `Topic` (`Topic`(3)) USING BTREE,
  KEY `VisibleID` (`Visible`,`ID`) USING BTREE,
  KEY `VisibleTimeLastModified` (`Visible`,`TimeLastModified`,`ID`) USING BTREE,
  KEY `TimeLastModifiedID` (`TimeLastModified`,`ID`) USING BTREE,
  KEY `DOI_INDEX` (`Doi`) USING BTREE,
  KEY `Identifier` (`Identifier`),
  KEY `classifybyoclc_calln_lcc` (`classifybyoclc_calln_lcc`),
  KEY `classifybyoclc_fast` (`classifybyoclc_fast`(300)),
  FULLTEXT KEY `Title` (`Title`),
  FULLTEXT KEY `Author` (`Author`),
  FULLTEXT KEY `Language` (`Language`),
  FULLTEXT KEY `Extension` (`Extension`),
  FULLTEXT KEY `Publisher` (`Publisher`),
  FULLTEXT KEY `Series` (`Series`),
  FULLTEXT KEY `Year` (`Year`),
  FULLTEXT KEY `Title1` (`Title`,`Author`,`Series`,`Publisher`,`Year`,`Periodical`,`VolumeInfo`),
  FULLTEXT KEY `Tags` (`Tags`),
  FULLTEXT KEY `Identifierfulltext` (`IdentifierWODash`)
) ENGINE=InnoDB AUTO_INCREMENT=3246566 DEFAULT CHARSET=utf8 
    
CREATE TABLE `LOC_Classification_Text_zFULL_YYY` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `reference` longtext COLLATE utf8mb4_unicode_ci,
  `data` longtext COLLATE utf8mb4_unicode_ci,
  `crcomment` longtext COLLATE utf8mb4_unicode_ci,
  `groupname` longtext COLLATE utf8mb4_unicode_ci,
  `code` longtext COLLATE utf8mb4_unicode_ci,
  `indentation` int(10) unsigned DEFAULT NULL,
  `path` longtext COLLATE utf8mb4_unicode_ci,
  `specialtag` longtext COLLATE utf8mb4_unicode_ci,
  `specialtag_cat` mediumtext COLLATE utf8mb4_unicode_ci,
  `specialtag_master` mediumtext COLLATE utf8mb4_unicode_ci,
  `specialtag_master_cat` mediumtext COLLATE utf8mb4_unicode_ci,
  `specialtag_override_cat_moddetails` mediumtext COLLATE utf8mb4_unicode_ci,
  `specialtag_override_cat_timestamp` mediumtext COLLATE utf8mb4_unicode_ci,
  `specialtag_override_cat` mediumtext COLLATE utf8mb4_unicode_ci,
  `pageno` longtext COLLATE utf8mb4_unicode_ci,
  `specialtag_escalated` longtext COLLATE utf8mb4_unicode_ci,
  `history` longtext COLLATE utf8mb4_unicode_ci,
  `history_classification` longtext COLLATE utf8mb4_unicode_ci,
  `specialtag_esc_start` longtext COLLATE utf8mb4_unicode_ci,
  `specialtag_esc_start_type` longtext COLLATE utf8mb4_unicode_ci,
  `callCore` varchar(256) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `d1` longtext COLLATE utf8mb4_unicode_ci,
  `d2` longtext COLLATE utf8mb4_unicode_ci,
  `d3` longtext COLLATE utf8mb4_unicode_ci,
  `d4` longtext COLLATE utf8mb4_unicode_ci,
  `d5` longtext COLLATE utf8mb4_unicode_ci,
  `d6` longtext COLLATE utf8mb4_unicode_ci,
  `d7` longtext COLLATE utf8mb4_unicode_ci,
  `d8` longtext COLLATE utf8mb4_unicode_ci,
  `d9` longtext COLLATE utf8mb4_unicode_ci,
  `d10` longtext COLLATE utf8mb4_unicode_ci,
  `d11` longtext COLLATE utf8mb4_unicode_ci,
  `d12` longtext COLLATE utf8mb4_unicode_ci,
  PRIMARY KEY (`id`),
  KEY `indentation` (`indentation`),
  KEY `callCore` (`callCore`),
  FULLTEXT KEY `specialtag` (`specialtag`)
) ENGINE=InnoDB AUTO_INCREMENT=496218 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci |
    
    | a_sg1lib | CREATE TABLE `a_sg1lib` (
  `ida` int(11) DEFAULT '0',
  `classifybyoclc_respcode` text CHARACTER SET utf8mb4,
  `classifybyoclc_timest` text CHARACTER SET utf8mb4,
  `isbn` text CHARACTER SET utf8mb4,
  `choseStatus` varchar(256) CHARACTER SET utf8mb4 DEFAULT NULL,
  `choseStatus2` varchar(1000) CHARACTER SET utf8mb4 DEFAULT NULL,
  `choseStatusSpecial` varchar(256) CHARACTER SET utf8mb4 DEFAULT NULL,
  `choseStatusMarker` varchar(256) CHARACTER SET utf8mb4 DEFAULT NULL,
  `title` text CHARACTER SET utf8mb4,
  `subtitle` text CHARACTER SET utf8mb4,
  `publisher_name` text CHARACTER SET utf8mb4,
  `imprint_name` text CHARACTER SET utf8mb4,
  `publication_date` text CHARACTER SET utf8mb4,
  `edition_number` text CHARACTER SET utf8mb4,
  `authors` text CHARACTER SET utf8mb4,
  `editors` text CHARACTER SET utf8mb4,
  `others` text CHARACTER SET utf8mb4,
  `contributors` text CHARACTER SET utf8mb4,
  `is_activated` text CHARACTER SET utf8mb4,
  `public_url` text CHARACTER SET utf8mb4,
  `date_added` text CHARACTER SET utf8mb4,
  `format` text CHARACTER SET utf8mb4,
  `rating` text CHARACTER SET utf8mb4,
  `engagement_score` text CHARACTER SET utf8mb4,
  `university_list_count` text CHARACTER SET utf8mb4,
  `published_list_count` text CHARACTER SET utf8mb4,
  `award_count` text CHARACTER SET utf8mb4,
  `mobile_disabled` text CHARACTER SET utf8mb4,
  `categories` text CHARACTER SET utf8mb4,
  `year` text CHARACTER SET utf8mb4,
  `subjects` text CHARACTER SET utf8mb4,
  `topics` text CHARACTER SET utf8mb4,
  `topics_facet_filter` text CHARACTER SET utf8mb4,
  `topics_detailed` text CHARACTER SET utf8mb4,
  `main_subject` text CHARACTER SET utf8mb4,
  `main_topic` text CHARACTER SET utf8mb4,
  `keywords` text CHARACTER SET utf8mb4,
  `description` text CHARACTER SET utf8mb4,
  `language_id` text CHARACTER SET utf8mb4,
  `language` varchar(256) CHARACTER SET utf8mb4 DEFAULT NULL,
  `sales_rights` text CHARACTER SET utf8mb4,
  `cover_image` text CHARACTER SET utf8mb4,
  `related_isbns` text CHARACTER SET utf8mb4,
  `file_size` text CHARACTER SET utf8mb4,
  `mobile_disabled_v3` text CHARACTER SET utf8mb4,
  `is_restricted` text CHARACTER SET utf8mb4,
  `organisation_list` text CHARACTER SET utf8mb4,
  `objectID` text CHARACTER SET utf8mb4,
  `_highlightResult` text CHARACTER SET utf8mb4,
  `chapters` text CHARACTER SET utf8mb4,
  `Zstatus_retrieve_TOC` text CHARACTER SET utf8mb4,
  `Zstatus_retrieve_classifybyoclc` text CHARACTER SET utf8mb4,
  `pid` text CHARACTER SET utf8mb4,
  `ida2` int(11) DEFAULT NULL,
  `withdrawal_date` text CHARACTER SET utf8mb4,
  `book_id` int(13) DEFAULT NULL,
  `classifybyoclc_calln_lcc` varchar(256) CHARACTER SET utf8mb4 DEFAULT NULL,
  `classifybyoclc_calln_ddc` text CHARACTER SET utf8mb4,
  `classifybyoclc_calln_nlm` text CHARACTER SET utf8mb4,
  `classifybyoclc_fast` varchar(960) CHARACTER SET utf8mb4 DEFAULT NULL,
  `classifybyoclc_owi` text CHARACTER SET utf8mb4,
  `classifybyoclc_fast_max` varchar(512) CHARACTER SET utf8mb4 DEFAULT NULL,
  `id` int(10) unsigned DEFAULT '0',
  `reference` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `data` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `crcomment` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `groupname` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `code` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `indentation` int(10) unsigned DEFAULT NULL,
  `path` varchar(1000) DEFAULT NULL,
  `specialtag` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `specialtag_cat` text CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `specialtag_master` text CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `specialtag_master_cat` text CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `specialtag_override_cat_moddetails` text CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `specialtag_override_cat_timestamp` text CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `specialtag_override_cat` text CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `pageno` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `specialtag_escalated` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `history` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `history_classification` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `specialtag_esc_start` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `specialtag_esc_start_type` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `callCore` varchar(256) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `d1` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d2` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d3` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d4` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d5` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d6` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d7` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d8` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d9` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d10` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d11` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `d12` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `idmaster` int(11) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`idmaster`),
  KEY `choseStatus` (`choseStatus`),
  KEY `classifybyoclc_calln_lcc` (`classifybyoclc_calln_lcc`),
  KEY `book_id` (`book_id`),
  KEY `path` (`path`),
  KEY `choseStatusSpecial` (`choseStatusSpecial`),
  KEY `choseStatusMarker` (`choseStatusMarker`),
  KEY `choseStatus2` (`choseStatus2`(256)) USING BTREE,
  FULLTEXT KEY `title` (`title`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |

I thought what makes the query so slow is the fact that one of the tables is MyISAM, and tried to change that, but even that takes forever.我认为使查询如此缓慢的原因是其中一个表是 MyISAM,并试图改变它,但即使这样也需要很长时间。 Altering the columns involved in the join from TEXT to VARCHAR also takes forever ;(;(. Basically I am stuck ;(将连接中涉及的列从 TEXT 更改为 VARCHAR 也需要永远;(;(。基本上我被卡住了 ;(

May I know what is wrong, and how can I make this faster?我可以知道什么是错的,我怎样才能让它更快?

SHOW CREATE TABLE is more descriptive than DESCRIBE . SHOW CREATE TABLEDESCRIBE更具描述性。 In particular, I need to see if the indexes are composite and, if so, what order the columns are in.特别是,我需要查看索引是否是复合的,如果是,列的顺序是什么。

RU_sg1lib_classifybyoclc:  INDEX(classifybyoclc_calln_lcc)

If it turns out that that is really a JOIN instead of a RIGHT JOIN , then this might be useful:如果事实证明这确实是JOIN而不是RIGHT JOIN ,那么这可能很有用:

LOC_Classification_Text_zFULL_YYY:  INDEX(callCore)

I suspect that most of the columns are declared larger than necessary.我怀疑大多数列都被声明为大于必要的。 Shrinking them may help some.缩小它们可能会有所帮助。 For example, the 8-byte BIGINT is usually bigger than will ever be needed.例如,8 字节的BIGINT通常比以往任何时候都大。 year and some ids are unnecessarily (and inefficiently) TEXT . year和一些ids是不必要的(而且效率低下) TEXT

forgodsakehold, We should talk if this is not clear. forgodskehold,如果不清楚,我们应该谈谈。 View my profile for contact info, please.请查看我的个人资料以获取联系信息。

Observation 1,观察 1,

RU_sg1lib_classifybyoclc.ID appears to be INT(15) unsigned 
SELECTED for push into a_sg11lib table as book_id

and

a_sg1lib.book_id appears to be simple INT(13)  (NOT unsigned and diff lengths)

most often we see same column attributes when moving data.大多数情况下,我们在移动数据时会看到相同的列属性。

Observation 2, RIGHT JOIN of calln_lcc = to callCore观察 2,calln_lcc 的 RIGHT JOIN = 到 callCore

RU_sg1lib_classifbyoclc.classifybyoclc_calln_lcc is simple varchar(256)

and

LOC_Classification_Text_zFULL_YYY.callcore is varchar(256) COLLATE utf8mb4_unicode_ci 

most often we see matched column definitions for left and right side of =.大多数情况下,我们会看到 = 左侧和右侧的匹配列定义。

What's going on here to make this slow?这里发生了什么让这变慢? A few things.一些东西。

  • You have big tables and no WHERE clause, so this statement handles a lot of data.您有大表并且没有 WHERE 子句,因此该语句处理大量数据。 It's never going to be sub-minute fast.它永远不会快到分分钟。

  • Your tables have many CLOB (mediumtext, longtext) columns.您的表有许多 CLOB (mediumtext, longtext) 列。 The way MySQL stores those columns makes retrieving and storing them surprisingly expensive. MySQL 存储这些列的方式使得检索和存储它们非常昂贵。 Your query insists on retrieving them all and storing them again.您的查询坚持检索它们并再次存储它们。

  • You correctly identified the mix of MyISAM and InnoDB tables as a possible performance problem.您正确地将 MyISAM 和 InnoDB 表的混合识别为可能的性能问题。 But , your table definitions show InnoDB tables, so you may have successfully converted one of them.但是,您的表定义显示了 InnoDB 表,因此您可能已成功转换其中之一。 That's good.那挺好的。

  • You're joining on this:你正在加入这个:

     ON `RU_sg1lib_classifybyoclc`.`classifybyoclc_calln_lcc` = `loc_classification`.`LOC_Classification_Text_zFULL_YYY`.`callCore`;

    It's very important to performance that the columns in your ON-clauses have precisely the same definition. ON 子句中的列具有完全相同的定义对性能非常重要 The declaration of classifybyoclc_calln_lcc in RU_sg1lib_classifybyoclc lacks both its own COLLATE clause and a default COLLATE for the table, so its collation is unknown. RU_sg1lib_classifybyoclc中的classifybyoclc_calln_lcc声明缺少自己的COLLATE 子句和表的默认COLLATE,因此它的排序规则是未知的。 It is the database's default, which we don't know.这是数据库的默认值,我们不知道。

     varchar(256) CHARACTER SET utf8mb4 DEFAULT NULL

    The declaration of callCore in LOC_Classification_Text_zFULL_YYY is this. callCoreLOC_Classification_Text_zFULL_YYY的声明是这样的。

     varchar(256) COLLATE utf8mb4_unicode_ci DEFAULT NULL,

    If your database default collation is also utf8mb4_unicode_ci you should be in good shape.如果您的数据库默认排序规则也是utf8mb4_unicode_ci您应该处于良好状态。 Otherwise alter the first table to specify the collation for classifybyoclc_calln_lcc explicitly.否则,更改第一个表以显式指定分类分类的排序classifybyoclc_calln_lcc

  • It's possible you could store those OCLC call numbers using CHARACTER SET latin1 COLLATE latin1_bin .您可以使用CHARACTER SET latin1 COLLATE latin1_bin存储这些OCLC 电话号码 They may not need to be case-insensitive and they may not contain characters outside the ASCII and western European character sets.它们可能不需要区分大小写,并且它们可能不包含 ASCII 和西欧字符集之外的字符。 If your call numbers work like that, you might alter your tables to use the more efficient collation.如果您的电话号码是这样工作的,您可能会更改您的表格以使用更有效的排序规则。 Latin-1 text takes a quarter as many bytes to store in indexes as utfmb4 text. Latin-1 文本在索引中存储的字节数是 utfmb4 文本的四分之一。 If you need case-insensitive searching on the call numbers, use COLLATE latin1_general_ci .如果您需要对索书号进行不区分大小写的搜索,请使用COLLATE latin1_general_ci

  • RIGHT JOIN is just plain weird. RIGHT JOIN很奇怪。 Almost everybody uses LEFT JOIN , reversing the order of your two tables.几乎每个人都使用LEFT JOIN ,颠倒两个表的顺序。 Do you really need an outer join like that?你真的需要这样的外部连接吗? If you don't need an outer join, use an ordinary INNER join.如果您不需要外部联接,请使用普通的内部INNER

What can you do about this?你能做些什么呢? You didn't tell us why you need that a_sg1lib table.您没有告诉我们为什么需要该a_sg1lib表。 If you're using it with queries containing WHERE clauses, to find just a few rows at a time, you could create a VIEW rather than a TABLE.如果您将它与包含 WHERE 子句的查询一起使用,一次只查找几行,您可以创建一个 VIEW 而不是 TABLE。 Each lookup will then use the indexes on your existing tables, and you won't have to copy the data.然后,每次查找都将使用现有表上的索引,而您不必复制数据。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM