1.10.5 То, что надо сделать когда-нибудь

• Реализовать функцию: get_changed_tables(timeout,table1,table2,...).
• Изменить чтение таблиц так, чтобы везде, где возможно. использовалась memmap. Сейчас memmap используется только для уплотненных таблиц.
• Сделать лучше автоматический код временных меток (timestamp). Добавлять временные метки в журнал обновлений при помощи SET TIMESTAMP=#;.
• Использовать в некоторых местах семафор чтения/записи для увеличения скорости.
• Обеспечить полную поддержку внешних ключей в MyISAM-таблицах (возможно, после реализации хранимых процедур с триггерами).
• Подготовить простые обзоры (сначала по одной таблице, позднее по любому выражению).
• Реализовать автоматическое закрытие некоторых таблиц, если таблица, временная таблица или временные файлы получат ошибку 23 (недостаточно открытых файлов).
• Если обнаружится поле=#, заменить все местонахождения поля на #. Сейчас такое делается только для некоторых простых случаев.
• Заменить все константные выражения вычисляемыми, если возможно.
• Реализовать оптимизацию ключ=выражение. К данному моменту делается оптимизация только для ключ=поле или ключ=константа.
• Связывать некоторые функции копирования для улучшения кода.
• Заменить sql_yacc.yy внутритекстовым синтаксическим анализатором, чтобы уменьшить ее размер и получать лучшие сообщения об ошибке (5 дней).
• Изменить собственный синтаксический анализатор так, чтобы он использовал только одно правило для различного количества аргументов в функции.
• Использовать полные вычисляемые имена в части сортировки (для ACCESS97).
• MINUS, INTERSECT и FULL OUTER JOIN (в настоящее время поддерживаются UNION [в 4.0] и LEFT OUTER JOIN).
• SQL_OPTION MAX_SELECT_TIME=#, чтобы устанавливать ограничения по времени для запроса.
• Сделать так, чтобы обновляемый журнал записывался в базу данных..
• Сделать добавления в LIMIT, чтобы можно было делать восстановление данных с конца результирующего набора.
• Сигналы предупреждений для функций соединения/чтения/записи клиента.
• Необходимо обратить внимание на изменения на safe_mysqld; согласно FSSTND (которому пытается следовать Debian) PID-файлы должны помещаться в `/var/run/<progname>.pid', a файлы журналов - в `/var/log'. Было бы хорошо, если бы было можно поместить "`DATADIR'" в первое объявление "`pidfile'" и "`log'", чтобы местоположение этих файлов можно было изменить одним оператором.
• Разрешать клиенту запрашивать ведение журналов.
• Добавить использование zlib() для gzip-файлов в LOAD DATA INFILE.
• Исправить сортировку и группирование BLOB-столбцов (сейчас проблема частично решена).
• Хранимые процедуры. Рассматриваются также триггеры.
• Простой (атомарный) язык обновления, который может быть использован для написания циклов и т.п. в MySQL-сервере.
• Произвести изменения для того, чтобы пользоваться семафорами при подсчете потоков. Но сначала нужно реализовать библиотеку семафоров для потоков MIT-pthreads.
• Не устанавливать новое значение во время установки колонки в 0. вместо этого использовать NULL.
• Добавить полную поддержку круглых скобок для JOIN.
• В качестве альтернативы одному потоку/соединению управлять пулом потоков при обработке запросов.
• Обеспечить возможность получать более чем одну блокировку при помощи GET_LOCK. Когда это будет реализовано, потребуется еще сделать обработку возможных тупиковых ситуаций, которые привнесет данное изменение.

Время отводится согласно объемам работ, а не реальному времени.

User Comments

As far as I know, performance increases
incredibly rewriting a NOT IN subquery in the
form of a NOT EXISTS subquery, due to the use of
indexes. (This i have vefified in Oracle and
Sybase DBMSs).
I don't know how performance is affected when
using the left join approach for rewriting
queries with Not exists. Hope it doesn't affect
much, though.

Using OUTER Table joins seems to have provided a
workaround, unless someone knows of other
issues. I tried this on my sql and it worked
great.

SELECT r.resumename, s.stateprovincename,
e.educationlevelname, t.travelamountname
FROM Resumes r
left outer join
stateprovinces s on r.stateprovinceid =
s.stateprovinceid
left outer join
educationlevels e on r.educationlevelid =
e.educationlevelid
left outer join
travelamounts t on r.travelamountid =
t.travelamountid

is the same as....

SELECT r.resumename,
(select stateprovinename from
stateprovinces
where stateprovinceid =
r.stateprovinceid) as stateprovincename

(etc. add more subselects here...)

FROM resumes r

Modify CREATE TABLE syntax to accept COMMENTs on
fields of the table, so that DESCRIBE may be used
to retrieve the documentation of the fields.
This saves having to maintain field comments
separately from their definiton. Field comments
are important in describing the field's purpose
and use.

QUOTE
SELECT * FROM table1 WHERE NOT EXISTS (SELECT id
FROM table2 where table1.id=table2.id);

Can be rewritten as:

SELECT table1.* FROM table1 LEFT JOIN table2 ON
table1.id=table2.id where table2.id IS NULL
END_QUOTE

A query can be re-written like above, but please
note that they are definitely _not_ equivalent.
The second query will give duplicate rows if
table2 has duplicate ids from table 1 whereas the
first query will only return single rows from
table 1. In fact it is impossible as things stand
to code a 'where exists' equivalent without the
risk of returning multiple rows.

In response to:
"DECIMAL and NUMERIC types can't read exponential
numbers; Field_decimal::store(const char
*from,uint len) must be recoded to fix this."

The
workaround we have implemented is to read in
numeric columns to "varchar" fields. Bizarre-o.

Point in time recovery would be nice. Actually,
required, for ACID. Also, you cannot recover a
table and maintain ACID, unless there have been
no cross-table transactions (unlikely) so
removing that feature would probably be a good
idea.

Regarding the need for EXISTS support, I would be
satisfied with a solution which involved some sort of
bastardization of the LEFT JOIN which produced
similar functionality such as having "LEFT FIRST
JOIN" mean that the table on the right only returns
the first matching record. Or what about having
LEFT EXISTS JOIN mean that the table on the right
only returns an "exists" element. So this would be
possible: SELECT a.*, b.exists FROM Table1 a LEFT
EXISTS JOIN Table2 b ON a.SomeID=b.SomeID.
Sure adding non-standard SQL is gross, but I'd love
to be able to more easily port to MySQL from MS
SQL Server, and EXISTS might be more of a pain to
impliment than a bastardization of the LEFT OUTER
JOIN.

Add your own comment.