📄 manual_bugs.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0071)manual_Bugs.html -->
<html>
<head>
<title>MySQL Reference Manual for version 3.23.7-alpha. - E Known errors and design
deficiencies in MySQL</title>
<meta content="text/html; charset=gb2312" http-equiv="Content-Type">
<!-- This HTML file has been created by texi2html 1.52 (hacked by david@detron.se)
from /dr1/my/masters/mysql-3.23/Docs/manual.texi on 9 December 1999 -->
<meta content="Microsoft FrontPage 3.0" name="GENERATOR">
</head>
<body bgColor="#ffffff" link="#101090" text="#000000" vLink="#7030b0">
<p>Go to the <a href="manual_Introduction.html">first</a>, <a href="manual_News.html">previous</a>,
<a href="manual_TODO.html">next</a>, <a href="manual_Concept_Index.html">last</a> section,
<a href="manual_toc.html">table of contents</a>. </p>
<hr>
<h1><a href="manual_toc.html#Bugs" name="Bugs">E Known errors and design deficiencies in
MySQL</a></h1>
<ul>
<li>You cannot build in another directory when using MIT-pthreads. Since this requires
changes to MIT-pthreads, we are not likely to fix this. </li>
<li><code>BLOB</code> values can't ``reliably'' be used in <code>GROUP BY</code> or <code>ORDER
BY</code> or <code>DISTINCT</code>. Only the first <code>max_sort_length</code> bytes
(default 1024) are used when comparing <code>BLOB</code>bs in these cases. This can be
changed with the <code>-O max_sort_length</code> option to <code>mysqld</code>. A
workaround for most cases is to use a substring: <code>SELECT DISTINCT LEFT(blob,2048)
FROM tbl_name</code>. </li>
<li>Calculation is done with <code>BIGINT</code> or <code>DOUBLE</code> (both are normally
64 bits long). It depends on the function which precision one gets. The general rule is
that bit functions are done with <code>BIGINT</code> precision, <code>IF</code>, and <code>ELT()</code>
with <code>BIGINT</code> or <code>DOUBLE</code> precision and the rest with <code>DOUBLE</code>
precision. One should try to avoid using bigger unsigned long long values than 63 bits
(9223372036854775807) for anything else than bit fields! </li>
<li>All string columns, except <code>BLOB</code> and <code>TEXT</code> columns,
automatically have all trailing spaces removed when retrieved. For <code>CHAR</code> types
this is okay, and may be regarded as a feature according to ANSI SQL92. The bug is that in
<strong>MySQL</strong>, <code>VARCHAR</code> columns are treated the same way. </li>
<li>You can only have up to 255 <code>ENUM</code> and <code>SET</code> columns in one table.
</li>
<li><code>safe_mysqld</code> re-directs all messages from <code>mysqld</code> to the <code>mysqld</code>
log. One problem with this is that if you execute <code>mysqladmin refresh</code> to close
and reopen the log, <code>stdout</code> and <code>stderr</code> are still redirected to
the old log. If you use <code>--log</code> extensively, you should edit <code>safe_mysqld</code>
to log to <tt>`'hostname'.err'</tt> instead of <tt>`'hostname'.log'</tt> so you can easily
reclaim the space for the old log by deleting the old one and executing <code>mysqladmin
refresh</code>. </li>
<li>In the <code>UPDATE</code> statement, columns are updated from left to right. If you
refer to a updated column, you will get the updated value instead of the original value.
For example: <pre>mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1
</pre>
<p>will update <code>KEY</code> with <code>2</code> instead of with <code>1</code>. </p>
</li>
<li>You can't use temporary tables more than once in the same query. <pre>select * from temporary_table, temporary_table as t2;
</pre>
</li>
</ul>
<p>The following is known bugs in earlier versions of <strong>MySQL</strong>:
<ul>
<li>Before <strong>MySQL</strong> 3.23.2 an <code>UPDATE</code> that updated a key with a <code>WHERE</code>
on the same key may have failed because the key was used to search for records and the
same row may have been found multiple times: <pre>UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100;
</pre>
<p>A workaround is to use: </p>
<pre>mysql> UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100;
</pre>
<p>This will work because <strong>MySQL</strong> will not use index on expressions in the <code>WHERE</code>
clause. </p>
</li>
<li>Before <strong>MySQL</strong> 3.23 all numeric types where treated as fixed-point
fields. That means you had to specify how many decimals a floating-point field shall have.
All results was returned with the correct number of decimals. </li>
</ul>
<p>For platform-specific bugs, see the sections about compiling and porting. </p>
<p><a name="IDX838"></a> </p>
<hr>
<p>Go to the <a href="manual_Introduction.html">first</a>, <a href="manual_News.html">previous</a>,
<a href="manual_TODO.html">next</a>, <a href="manual_Concept_Index.html">last</a> section,
<a href="manual_toc.html">table of contents</a>. </p>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -