[MDEV-16557] Remove INNOBASE_SHARE::idx_trans_tbl Created: 2018-06-25  Updated: 2019-03-15  Resolved: 2018-08-21

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 5.5, 10.0, 10.1, 10.2, 10.3, 10.4
Fix Version/s: 10.2.18, 10.3.10

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Eugene Kosov (Inactive)
Resolution: Fixed Votes: 0
Labels: alter, crash

Issue Links:
Relates
relates to MDEV-13671 InnoDB should use case-insensitive co... Closed
relates to MDEV-6443 Server crashed with assertaion failur... Closed
relates to MDEV-13425 Signal 11 on get_share() inside HASH_... Closed
relates to MDEV-13564 TRUNCATE TABLE and undo tablespace tr... Closed
relates to MDEV-18933 Hang on shutdown in rec_get_next_offs... Closed

 Description   

InnoDB internally stores the indexes of a table in SYS_INDEXES, ordered by the internal hidden key dict_index_t::id. Ever since InnoDB started to support ADD INDEX without rebuilding the whole table (first, in the InnoDB Plugin for MySQL 5.1), it became possible for the internal ordering of InnoDB dict_table_t::indexes to differ from the ordering of TABLE::key_info[]. To solve this inconsistency, an additional data structure INNOBASE_SHARE::idx_trans_tbl was added to map SQL key numbers to InnoDB indexes. But, as reported in MDEV-6443, there appear to be some glitches when it comes to updating this mapping.

We should remove the INNOBASE_SHARE::idx_trans_tbl, and instead change the dict_table_t::indexes to be sorted not by dict_index_t::id but according to the same rules as TABLE::keys[].

 Comments   
Comment by Marko Mäkelä [ 2018-06-25 ]

It might be best to sort the dict_table_t::indexes when ha_innobase::open() is called. Not every time, but:

  • when the table definition is being loaded due to the ha_innobase::open() call, or
  • when ha_innobase::open() is invoked for the first time since the table definition was loaded into InnoDB, or
  • when ha_innobase::open() is invoked for the first time since ha_innobase::commit_inplace_alter_table() was invoked on the table.

The sorting should be protected by dict_sys.mutex. If a mismatch between the TABLE and dict_table_t is found, an error or a warning should be reported to the server error log.

While sorting, we would necessarily check for mismatches in the indexes of the table. We could also check for mismatches in the column definitions, and deny access to the table from SQL altogether if the column definitions differ.

Comment by Marko Mäkelä [ 2018-08-01 ]

Thank you! I think that the title can be changed to "Remove INNOBASE_SHARE". I think that the rest of the structure only serves for looking up the table, so that idx_trans_tbl can be accessed.

I agree with you that we should try to remove the sorting and just search indexes by name. That should be measured with a benchmark, such as, defining indexes on 32 different columns, and having 64-char index names (192-byte; using 3-byte UTF-8 glyphs) that differ in the last character. Then, profile the execution of SELECT * FROM t WHERE col1=0 LIMIT 1 (and so on, for each indexed column) with the different approaches.

Comment by Eugene Kosov (Inactive) [ 2018-08-01 ]

Just searching by name results in performance loss.

--source include/have_innodb.inc
 
 
 
set names utf8;
 
 
 
create table t (
 
  a1 int,
 
  a2 int,
 
  a3 int,
 
  a4 int,
 
  a5 int,
 
  a6 int,
 
  a7 int,
 
  a8 int,
 
  a9 int,
 
  a10 int,
 
  a11 int,
 
  a12 int,
 
  a13 int,
 
  a14 int,
 
  a15 int,
 
  a16 int,
 
  a17 int,
 
  a18 int,
 
  a19 int,
 
  a20 int,
 
  a21 int,
 
  a22 int,
 
  a23 int,
 
  a24 int,
 
  a25 int,
 
  a26 int,
 
  a27 int,
 
  a28 int,
 
  a29 int,
 
  a30 int,
 
  a31 int,
 
  a32 int,
 
  a33 int,
 
  a34 int,
 
  a35 int,
 
  a36 int,
 
  a37 int,
 
  a38 int,
 
  a39 int,
 
  a40 int,
 
  a41 int,
 
  a42 int,
 
  a43 int,
 
  a44 int,
 
  a45 int,
 
  a46 int,
 
  a47 int,
 
  a48 int,
 
  a49 int,
 
  a50 int,
 
  a51 int,
 
  a52 int,
 
  a53 int,
 
  a54 int,
 
  a55 int,
 
  a56 int,
 
  a57 int,
 
  a58 int,
 
  a59 int,
 
  a60 int,
 
  a61 int,
 
  a62 int,
 
  a63 int,
 
  a64 int,
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀1(a1),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀2(a2),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀3(a3),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀4(a4),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀5(a5),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀6(a6),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀7(a7),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀8(a8),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀9(a9),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀10(a10),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀11(a11),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀12(a12),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀13(a13),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀14(a14),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀15(a15),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀16(a16),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀17(a17),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀18(a18),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀19(a19),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀20(a20),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀21(a21),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀22(a22),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀23(a23),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀24(a24),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀25(a25),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀26(a26),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀27(a27),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀28(a28),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀29(a29),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀30(a30),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀31(a31),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀32(a32),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀33(a33),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀34(a34),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀35(a35),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀36(a36),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀37(a37),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀38(a38),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀39(a39),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀40(a40),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀41(a41),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀42(a42),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀43(a43),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀44(a44),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀45(a45),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀46(a46),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀47(a47),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀48(a48),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀49(a49),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀50(a50),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀51(a51),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀52(a52),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀53(a53),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀54(a54),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀55(a55),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀56(a56),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀57(a57),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀58(a58),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀59(a59),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀60(a60),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀61(a61),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀62(a62),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀63(a63),
 
  unique key ☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀☀64(a64)
 
) engine=innodb;
 
 
 
insert into t values (1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1);
 
let $i = 10485;#76;
 
 
 
--disable_query_log
 
while ($i) {
 
eval select * from t where
 
  a1=1 and
 
  a2=1 and
 
  a3=1 and
 
  a4=1 and
 
  a5=1 and
 
  a6=1 and
 
  a7=1 and
 
  a8=1 and
 
  a9=1 and
 
  a10=1 and
 
  a11=1 and
 
  a12=1 and
 
  a13=1 and
 
  a14=1 and
 
  a15=1 and
 
  a16=1 and
 
  a17=1 and
 
  a18=1 and
 
  a19=1 and
 
  a20=1 and
 
  a21=1 and
 
  a22=1 and
 
  a23=1 and
 
  a24=1 and
 
  a25=1 and
 
  a26=1 and
 
  a27=1 and
 
  a28=1 and
 
  a29=1 and
 
  a30=1 and
 
  a31=1 and
 
  a32=1 and
 
  a33=1 and
 
  a34=1 and
 
  a35=1 and
 
  a36=1 and
 
  a37=1 and
 
  a38=1 and
 
  a39=1 and
 
  a40=1 and
 
  a41=1 and
 
  a42=1 and
 
  a43=1 and
 
  a44=1 and
 
  a45=1 and
 
  a46=1 and
 
  a47=1 and
 
  a48=1 and
 
  a49=1 and
 
  a50=1 and
 
  a51=1 and
 
  a52=1 and
 
  a53=1 and
 
  a54=1 and
 
  a55=1 and
 
  a56=1 and
 
  a57=1 and
 
  a58=1 and
 
  a59=1 and
 
  a60=1 and
 
  a61=1 and
 
  a62=1 and
 
  a63=1 and
 
  a64=1;
 
  flush table t;
 
  dec $i;
 
}
 
--enable_query_log
 
 
 
drop table t;

Test search for every index by name on table open. And it happens on every iteration because of `FLUSH TABLE`.

Benchmark results are:

  10.2:
 
15.325
 
14.329
 
14.269
 
sum = 43.923
 
 
 
  search by name:
 
21.399
 
21.225
 
21.306
 
sum = 63.93
 
 
 
63.92 / 43.923 = 1.45 => 45% performance loss

10.2 profile:

    67.15%  mysqld              [.] my_strcasecmp_utf8
 
     1.97%  mysqld              [.] _Z10MYSQLparseP3THD
 
     1.30%  mysqld              [.] _ZL19update_ref_and_keysP3THDP16st_dynamic_arrayP13st_join_tablejP4ItemyP13st_select_lexPP14SARGABLE_PARAM
 
     1.11%  mysqld              [.] _ZN10Item_equal8containsEP5Field
 
     0.86%  mysqld              [.] _Z28dict_table_get_index_on_nameP12dict_table_tPKcb
 
     0.85%  libc-2.27.so        [.] __memmove_avx_unaligned_erms
 
     0.82%  libc-2.27.so        [.] __strlen_avx2
 
     0.74%  mysqld              [.] _ZL13lex_one_tokenP7YYSTYPEP3THD
 
     0.71%  mysqld              [.] strnmov
 
     0.68%  mysqld              [.] _ZN5Field2eqEPS_
 
     0.67%  mysqld              [.] alloc_root
 
     0.59%  mysqld              [.] _ZL20build_template_fieldP14row_prebuilt_tP12dict_index_tS2_P5TABLEPK5Fieldmm
 
     0.45%  mysqld              [.] _ZN11TABLE_SHARE26init_from_binary_frm_imageEP3THDbPKhm
 
     0.43%  libc-2.27.so        [.] __strcmp_sse2_unaligned
 
     0.38%  mysqld              [.] _Z19innobase_strcasecmpPKcS0_
 
     0.29%  mysqld              [.] _ZL21check_simple_equalityP3THDRKN12Value_source7ContextEP4ItemS6_P10COND_EQUAL
 
     0.28%  mysqld              [.] my_hash_sort_utf8_nopad
 
     0.25%  mysqld              [.] _ZN8TaoCrypt3MD59TransformEv
 
     0.22%  mysqld              [.] _ZNK10Item_field11used_tablesEv
 
     0.21%  libc-2.27.so        [.] cfree@GLIBC_2.2.5
 
     0.21%  mysqld              [.] _ZN3THD19cleanup_after_queryEv
 
     0.19%  mysqld              [.] _ZN8Protocol16store_string_auxEPKcmPK15charset_info_stS4_
 
     0.19%  libc-2.27.so        [.] malloc

Search by name profile:

    79.87%  mysqld              [.] my_strcasecmp_utf8
 
     1.08%  mysqld              [.] _Z10MYSQLparseP3THD
 
     0.96%  mysqld              [.] _Z28dict_table_get_index_on_nameP12dict_table_tPKcb
 
     0.91%  mysqld              [.] _ZL19update_ref_and_keysP3THDP16st_dynamic_arrayP13st_join_tablejP4ItemyP13st_select_lexPP14SARGABLE_PARAM
 
     0.66%  mysqld              [.] _ZN10Item_equal8containsEP5Field
 
     0.52%  mysqld              [.] _Z19innobase_strcasecmpPKcS0_
 
     0.49%  libc-2.27.so        [.] __memmove_avx_unaligned_erms
 
     0.44%  mysqld              [.] _ZN5Field2eqEPS_
 
     0.42%  libc-2.27.so        [.] __strlen_avx2
 
     0.37%  mysqld              [.] strnmov
 
     0.36%  mysqld              [.] alloc_root
 
     0.34%  mysqld              [.] _ZL13lex_one_tokenP7YYSTYPEP3THD
 
     0.33%  mysqld              [.] _ZN11TABLE_SHARE26init_from_binary_frm_imageEP3THDbPKhm
 
     0.33%  mysqld              [.] _ZL20build_template_fieldP14row_prebuilt_tP12dict_index_tS2_P5TABLEPK5Fieldmm
 
     0.20%  mysqld              [.] _ZL21check_simple_equalityP3THDRKN12Value_source7ContextEP4ItemS6_P10COND_EQUAL

Comment by Eugene Kosov (Inactive) [ 2018-08-02 ]

PR updated. This version with strcmp() is actually faster:

  10.2:
 
15.345
 
15.352
 
15.400
 
 
 
 
 
  this patch:
 
9.313
 
8.332
 
9.266
 
 
 
 
 
    24.27%  libc-2.27.so        [.] __strcmp_sse2_unaligned
 
     4.32%  mysqld              [.] _Z10MYSQLparseP3THD
 
     3.83%  mysqld              [.] _ZL19update_ref_and_keysP3THDP16st_dynamic_arrayP13st_join_tablejP4ItemyP13st_select_lexPP14SARGABLE_PARAM
 
     2.45%  mysqld              [.] _ZN10Item_equal8containsEP5Field
 
     2.10%  libc-2.27.so        [.] __memmove_avx_unaligned_erms
 
     1.85%  mysqld              [.] _Z28dict_table_get_index_on_nameP12dict_table_tPKcb
 
     1.85%  libc-2.27.so        [.] __strlen_avx2
 
     1.74%  mysqld              [.] _ZL13lex_one_tokenP7YYSTYPEP3THD
 
     1.70%  mysqld              [.] _ZN5Field2eqEPS_
 
     1.54%  mysqld              [.] alloc_root
 
     1.50%  mysqld              [.] strnmov

Comment by Marko Mäkelä [ 2018-08-16 ]

Thank you!
I am a little uncertain if we can use strcmp(). As described in MDEV-13671, it is possible that the column names in TABLE_SHARE and InnoDB will differ in the case. But I would expect that whenever an index is created, InnoDB would take the name from the SQL layer (derived from the contents of the TABLE_SHARE or the .frm file). MariaDB does not support RENAME INDEX. So, I would expect the index names to be binary equal between TABLE_SHARE and InnoDB.

Nevertheless, I asked mleich to test this (bb-10.2-marko) with RQG.

Generated at Thu Feb 08 08:29:48 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.