- added join cache indication in EXPLAIN (Extra column).
- prefer filesort over full scan over
index for ORDER BY (because it's faster).
- when switching from REF to RANGE because
RANGE uses longer key turn off sort on
the head table only as the resulting
RANGE access is a candidate for join cache
and we don't want to disable it by sorting
on the first table only.
INSERT...ON DUPLICATE KEY UPDATE may cause error 1032:
"Can't find record in ..." if we are inserting into
InnoDB table unique index of partial key with
underlying UTF-8 string field.
This error occurs because INSERT...ON DUPLICATE uses a wrong
procedure to copy string fields of multi-byte character sets
for index search.
INSERT into InnoDB table may cause "ERROR 1062 (23000): Duplicate entry..."
errors or lost records after multi-row INSERT of the form:
"INSERT INTO t (id...) VALUES (NULL...) ON DUPLICATE KEY UPDATE id=VALUES(id)",
where "id" is an AUTO_INCREMENT column.
It happens because InnoDB handler forgets to save next insert id after
updating of auto_increment column with new values. As result of that
last insert id stored inside InnoDB dictionary tables differs from it's
cached thd->next_insert_id value.
A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset
caused a crash when a query with DISTINCT was executed by a loose scan
for an InnoDB table that had been emptied.
It's not possible to flush the global status variables in 5.0
Update test case so it works by recording the value of handle_rollback
before and compare it to the value after
If the error happens during DELETE IGNORE, nothing could be send to the
client, thus leaving it frozen expecting the reply.
The problem was that if some error occurred, it wouldn't be reported to
the client because of IGNORE, but neither success would be reported.
MySQL 4.1 would not freeze the client, but will report
ERROR 1105 (HY000): Unknown error
instead, which is also a bug.
The solution is to report success if we are in DELETE IGNORE and some
non-fatal error has happened.
The bug is present only in 4.1, will be null-merged to 5.0
For InnoDB, check value of thd->transaction.all.innodb_active_trans instead of thd->transaction.stmt.innobase_tid to see if we really need to rollback.
Currently SQL_BIG_RESULT is checked only at compile time.
However, additional optimizations may take place after
this check that change the sort method from 'filesort'
to sorting via index. As a result the actual plan
executed is not the one specified by the SQL_BIG_RESULT
hint. Similarly, there is no such test when executing
EXPLAIN, resulting in incorrect output.
The patch corrects the problem by testing for
SQL_BIG_RESULT both during the explain and execution
phases.
This bug report was two problems:
1) LAST_INSERT_ID() returns a value which does not exist in the table
2) the reporter would want it to return the autoinc id of the updated
row.
1) is a real bug, 2) is a feature request.
In July I implemented 2) in 5.1 (which automatically fixes 1).
This has not yet been documented or released, so is changeable.
Precisely, recently Paul and a user found an easy workaround to give
2), which works in 4.1-5.0-5.1. So I can revert my code for 2),
because it's not needed, that's what I do here;
we forget about 2) (we will document the workaround).
But when I revert my code for 2), 1) comes back. We solve 1) by saying
that if INSERT ON DUPLICATE KEY UPDATE updates a row, it's like a
regular UPDATE: LAST_INSERT_ID() should not be affected (instead of
returning a non-existent value).
So note: no behaviour change compared to the last released 5.1; just
a bugfix for 1).
WL#3397 Refactoring storage engine test cases (for falcon)
It contains fixes according to second code review.
- Remove any occurence of hardcoded assignments of storage engines
- Use variable names exact telling what it is used for
- Updated comments
- remove trailing spaces
