This is the first time I try to use MySQL for very large tables.
Experienced users warned me against possible problems with *index*
definition for large tables:
they claim MySQL indices are stored completely in memory, which is
problematic to me : I have a huge table and limited memory size
Am Sonntag, 27. August 2006 15:23 schrieb [EMAIL PROTECTED]:
To confirm that you would like
[EMAIL PROTECTED]
added to the mysql mailing list, please click on
the following link:
http://lists.mysql.com/s/mysql/44f19ce8d8f3f021/karel.dingeldey=criena.net
This confirmation serves two
- Original Message -
From: Karel W. Dingeldey [EMAIL PROTECTED]
To: mysql@lists.mysql.com
Sent: Sunday, August 27, 2006 6:57 PM
Subject: Re: confirm subscribe to mysql@lists.mysql.com
Am Sonntag, 27. August 2006 15:23 schrieb [EMAIL PROTECTED]:
To confirm that you would like
For best performance, you would want to have all your indexes stored
in RAM, certainly. Generally true of databases.
However, you do not have to have enough RAM to keep the indexes loaded.
You can configure MySQL to use as much RAM as is appropriate for your
machine. The online manual has
Hi,
I am doing this thru the phpmyadmin interface:
ALTER TABLE doc ALTER docts SET DEFAULT CURRENT_TIMESTAMP
However, it returns #1064 - You have an error in your SQL syntax near
'DEFAULTCURRENT_TIMESTAMP' at line 1
As you can see the error shows that DEFAULT an CURRENT_TIMESTAMP
Hello,
yesterday my server crashed. The harddisk got corrupted, including some MySQL
table files. So MySQL can't see some of its tables, although the table files
are visible on the filesystem. Is it possible to repair the files? It's a
MySQL 4.1 (Debian Sarge).
From one table I only have the
PS: I already tried with myisamchk -r -o *.MY*, but then all datasets
are gone and the table is empty. :-(
man myisamchk
I tried myisamchk already. But after running the above rescue attempt, the
tables are empty.
--
MySQL General Mailing List
For list archives:
At first - do not write anything on the corrupted disk until You have
finished rescuing data. As I understad the crash is connected to HW or
filesystem (FS) failure (HDD). In that case try to use fsck to repair FS
(if it is regular linux FS, like ext2 or ext3, for xfs there were some
other
PS: I already tried with myisamchk -r -o *.MY*, but then all datasets
are gone and the table is empty. :-(
man myisamchk
I tried myisamchk already. But after running the above rescue attempt, the
tables are empty.
Then I hope you made backups You, do keep backups right?
--
Chris
--
Evert wrote:
Hi all!
Who can tell me why the following does not work...?
When I do:
SELECT COUNT(*) AS counter FROM table1 WHERE condition1 = 'A' AND
condition2 IS NULL;
it returns:
+-+
| counter |
+-+
| 2 |
+-+
Then I do:
DELETE FROM table1 WHERE
Question, I specify with openssl is with --wth-openssl=/usr/contrib
and the config script chokes. What is this happening?
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
MySQL General Mailing List
For list archives:
At first - do not write anything on the corrupted disk until You have
finished rescuing data. As I understad the crash is connected to HW or
filesystem (FS) failure (HDD).
Ok, I will do it more clearly. The server has two harddisks, one for the
system, one for the data. The system harddisk
On filesystem level I made all rescue trials. My problem is, that only the
MYD
file is still available. I tried reconstructing it with myisamchk -r -o
table_name.MYD, but as I said without the wanted result.
MYD is your data, MYI is your indexes (Indexes are easy to rebuild, you
should not
Hello all,
Currently our application and MySQL server are on the same machine.
When should these be seperated?
What are the main reasons that we should be having a seperate DB server?
Ratheesh Bhat K J
Ratheesh K J wrote:
Hello all,
Currently our application and MySQL server are on the same machine.
When should these be seperated?
What are the main reasons that we should be having a seperate DB server?
There are at least three possible reasons. First, if your applications
are using
Ratheesh K J wrote:
Hello all,
Currently our application and MySQL server are on the same machine.
When should these be seperated?
When:
- your performance is dropping, and
- you have identified that your bottleneck is CPU usage, and
- both your MySQL server and your application
16 matches
Mail list logo
