database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +03:00
Code Activity

MDEV-32837 long unique does not work like unique key when using replace

Browse Source 
write_record() when performing REPLACE has an optimization:
- if the unique violation happened in the last unique key, then do UPDATE
- otherwise, do DELETE+INSERT

This patch changes the way of detecting if this optimization
can be applied if the table has long (hash based) unique
(i.e. UNIQUE..USING HASH) constraints.

Problem:

The old condition did not take into account that
TABLE_SHARE and TABLE see long uniques differently:
- TABLE_SHARE sees as HA_KEY_ALG_LONG_HASH and HA_NOSAME
- TABLE sees as usual non-unique indexes
So the old condition could erroneously decide that the UPDATE optimization
is possible when there are still some unique hash constraints in the table.

Fix:

- If the current key is a long unique, it now works as follows:

  UPDATE can be done if the current long unique is the last
  long unique, and there are no in-engine (normal) uniques.

- For in-engine uniques nothing changes, it still works as before:

  If the current key is an in-engine (normal) unique:
  UPDATE can be done if it is the last normal unique.
This commit is contained in:
Alexander Barkov
2024-01-10 15:35:25 +04:00
parent a7ee3bc58b
commit 97fcafb9ec
5 changed files with 213 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
sql/sql_insert.cc
View File

@ -1728,7 +1728,7 @@ int mysql_prepare_insert(THD *thd, TABLE_LIST *table_list,
/* Check if there is more uniq keys after field */
static int last_uniq_key(TABLE *table,uint keynr)
static int last_uniq_key(TABLE *table, const KEY *key, uint keynr)
{
/*
When an underlying storage engine informs that the unique key
@ -1748,7 +1748,7 @@ static int last_uniq_key(TABLE *table,uint keynr)
return 0;
while (++keynr < table->s->keys)
if (table->key_info[keynr].flags & HA_NOSAME)
if (key[keynr].flags & HA_NOSAME)
return 0;
return 1;
}
@ -2064,8 +2064,27 @@ int write_record(THD *thd, TABLE *table, COPY_INFO *info, select_result *sink)
tables which have ON UPDATE but have no ON DELETE triggers,
we just should not expose this fact to users by invoking
ON UPDATE triggers.
Note, TABLE_SHARE and TABLE see long uniques differently:
- TABLE_SHARE sees as HA_KEY_ALG_LONG_HASH and HA_NOSAME
- TABLE sees as usual non-unique indexes
*/
if (last_uniq_key(table,key_nr) &&
bool is_long_unique= table->s->key_info &&
table->s->key_info[key_nr].algorithm ==
HA_KEY_ALG_LONG_HASH;
if ((is_long_unique ?
/*
We have a long unique. Test that there are no in-engine
uniques and the current long unique is the last long unique.
*/
!(table->key_info[0].flags & HA_NOSAME) &&
last_uniq_key(table, table->s->key_info, key_nr) :
/*
We have a normal key - not a long unique.
Test is the current normal key is unique and
it is the last normal unique.
*/
last_uniq_key(table, table->key_info, key_nr)) &&
!table->file->referenced_by_foreign_key() &&
(!table->triggers || !table->triggers->has_delete_triggers()))
{