Re: Ineffective OPTIMIZE TABLES
Aha! You are precisely correct. Thank you! On 3 October 2010 21:16, Dan Nelson dnel...@allantgroup.com wrote: In the last episode (Oct 03), George Larson said: I have an InnoDB table with a 'Data_length' of 114688 and 'Data_free' of '3896508416'. If I'm correctly understanding what I've been reading, those are good conditions to optimize the table. I understand the part where it maps to 'ALTER' for InnoDB. However, nothing I do seems to affect anything. Whether using 'OPTIMIZE' or doing the 'ALTER' myself, there is no apparent difference. I've done the 'FLUSH TABLES' for good measure and the results of 'SHOW TABLE STATUS' are unchanged. I have this same thing happening on multiple tables, I just picked this particular one as an example. Are you using innodb_file_per_table=on ? If you aren't, then you are using the shared tablespace model, and you cannot recover unused space without dumping all your tables, deleting the ib_data* files, and restoring. MySQL 5.5.5 has finally switched the default to innodb_file_per_table=on, but if you are running any older version, you will need to set that value in your config file. http://dev.mysql.com/doc/refman/5.1/en/multiple-tablespaces.html -- Dan Nelson dnel...@allantgroup.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=george.g.lar...@gmail.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Some MySQL Concerns
On Mon, Oct 4, 2010 at 3:03 AM, monloi perez mlp_fol...@yahoo.com wrote: 1) While inserting and connection lost, what will happen? Is the query going to be there forever? No. Depending on the timing of the connection loss, the statement may complete or be rolled back. it will not just hang there. Transactions will guarantee that not only the current insert, but the entire transaction is rolled back cleanly in case of a disconnect. 2) There are two engines for MySQL tables: InnoDB and MyISAM. It is said that the skip locking config is not working 100% for MyISAM tables and it's better to use InnoDB. Is this true? You shouldn't usually touch the skip-locking config :) 3) What is the impact if we switch engine for production tables from MyISAM to InnoDB? I tried this before and seems like you can just simply alter the table and change its storage engine, yet I just wanted to confirm. The very very VERY simplified answer is that if you're going to be using transactions, you must use InnoDB. If you're not using transactions, MyISAM may be slightly faster. Altering the engine on-the-fly is not a problem, indeed (keep in mind you're locking the table during the operation, though); but going from InnoDB to MyISAM will remove all defined foreign key relations; going from MyISAM to InnoDB requires you to remove any fulltext indices first. 4) MySQL thread_concurrency config: to split the queries into multiple CPUs. Does this really help a lot since currently we have a server with 8 cpu's and one with 16. MySQL is known to be not very good with multiple cores, although improvements keep being added, of course. A single query also executes always on a single CPU, no splitting happens. The Percona guys have done some excellent work making their XtraDB multithread very well, I hear; I'm not aware of wether they've done anything with query splitting. 5) MySQL wait_timeout config: the max time the server waits for activity on a noninteractive connection before closing it. What happens if an INSERT query exceeds max time. Will this corrupt our table since I guess the insert will be killed? or does the max time only work on selects? While a statement is running, your connection is not considered inactive. Sorry if its a lot, we just need some confirmations before we try to optimize our servers. Sounds like you want a DBA :-p -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel
Re: Indexing question
Hi! Neil Tompkins wrote: Thanks for your reply. So should we create individual indexes on each field or a multiple column index ?? This question cannot be answered without checking and measuring your installation. The decision whether to create an index is always an act of balancing: - If there is an index, the database server can use it to find data records by looking up the index, not scanning the base data. This results in load reduction (both CPU and disk IO) and speeds up query execution. - If there is an index, the database server must maintain it whenever data are altered (insert/update/delete), in addition to the base data. This is increased load (both CPU and disk IO) and slows down data changes. So obviously you want to create only those indexes that are helpful for query execution: you will never (voluntarily) create an index on a column which isn't used in search conditions, or whose use is already provided by other indexes. Of the remaining candidate indexes, you will never (voluntarily) create one that provides less gain in searches than it costs in data changes. With MySQL, AFAIK there is the limitation that on one table only one index can be used. As a result, the choice of indexes to create depends on the searches executed by your commands, their relative frequency, and the frequency of data changes. To answer your other question: If you run aggregate functions (like SUM(), MIN(), or MAX()) on all records of a table, their results could be computed by accessing a matching index only. I don't know whether MySQL does this, I propose you check that yourself using EXPLAIN. If you run them on subsets of a table only, an index on that column will not help in general. In database implementations, there is the concept of a covering index: If you have an index on columns A and B of some table, its contents (without the base data) would suffice to answer SELECT SUM(B) WHERE A = x Again, I don't know whether MySQL does this, and I refer you to EXPLAIN. HTH, Jörg -- Joerg Bruehe, MySQL Build Team, joerg.bru...@oracle.com ORACLE Deutschland B.V. Co. KG, Komturstrasse 18a, D-12099 Berlin Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven Amtsgericht Muenchen: HRA 95603 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Indexing question
Jörg Thanks for the useful reply. Maybe I can EXPLAIN my select queries for you to advise if any changes need to be made ? Regards Neil On Mon, Oct 4, 2010 at 3:38 PM, Joerg Bruehe joerg.bru...@oracle.comwrote: Hi! Neil Tompkins wrote: Thanks for your reply. So should we create individual indexes on each field or a multiple column index ?? This question cannot be answered without checking and measuring your installation. The decision whether to create an index is always an act of balancing: - If there is an index, the database server can use it to find data records by looking up the index, not scanning the base data. This results in load reduction (both CPU and disk IO) and speeds up query execution. - If there is an index, the database server must maintain it whenever data are altered (insert/update/delete), in addition to the base data. This is increased load (both CPU and disk IO) and slows down data changes. So obviously you want to create only those indexes that are helpful for query execution: you will never (voluntarily) create an index on a column which isn't used in search conditions, or whose use is already provided by other indexes. Of the remaining candidate indexes, you will never (voluntarily) create one that provides less gain in searches than it costs in data changes. With MySQL, AFAIK there is the limitation that on one table only one index can be used. As a result, the choice of indexes to create depends on the searches executed by your commands, their relative frequency, and the frequency of data changes. To answer your other question: If you run aggregate functions (like SUM(), MIN(), or MAX()) on all records of a table, their results could be computed by accessing a matching index only. I don't know whether MySQL does this, I propose you check that yourself using EXPLAIN. If you run them on subsets of a table only, an index on that column will not help in general. In database implementations, there is the concept of a covering index: If you have an index on columns A and B of some table, its contents (without the base data) would suffice to answer SELECT SUM(B) WHERE A = x Again, I don't know whether MySQL does this, and I refer you to EXPLAIN. HTH, Jörg -- Joerg Bruehe, MySQL Build Team, joerg.bru...@oracle.com ORACLE Deutschland B.V. Co. KG, Komturstrasse 18a, D-12099 Berlin Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven Amtsgericht Muenchen: HRA 95603
MySQL DB Version
Account Number : uk600724 Dear Sir/Madam, The MySQL database version which you have supplied to us is version 5.0.77. However, it would appear that we require version to be at least 5.1.43. How can we get our MySQL db upgraded to this version or greater ? Regards Neil Tompkins
Re: MySQL DB Version
On 10/4/2010 12:32 PM, Tompkins Neil wrote: Account Number : uk600724 Dear Sir/Madam, The MySQL database version which you have supplied to us is version 5.0.77. However, it would appear that we require version to be at least 5.1.43. How can we get our MySQL db upgraded to this version or greater ? Regards Neil Tompkins If you are an official MySQL customer, log in your request to the support system at https://support.mysql.com/ If you need help with your account, email our administrative staff at support-feedb...@mysql.com Warmest regards, -- Shawn Green MySQL Principal Technical Support Engineer Oracle USA, Inc. Office: Blountville, TN -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
RE: Indexing question
Include the query, EXPLAIN output, and the relavant SHOW CREATE TABLE table \G output. Someone should be able to offer suggestions. -Original Message- From: Tompkins Neil [mailto:neil.tompk...@googlemail.com] Sent: Monday, October 04, 2010 8:54 AM To: Joerg Bruehe Cc: [MySQL] Subject: Re: Indexing question Jörg Thanks for the useful reply. Maybe I can EXPLAIN my select queries for you to advise if any changes need to be made ? Regards Neil On Mon, Oct 4, 2010 at 3:38 PM, Joerg Bruehe joerg.bru...@oracle.comwrote: Hi! Neil Tompkins wrote: Thanks for your reply. So should we create individual indexes on each field or a multiple column index ?? This question cannot be answered without checking and measuring your installation. The decision whether to create an index is always an act of balancing: - If there is an index, the database server can use it to find data records by looking up the index, not scanning the base data. This results in load reduction (both CPU and disk IO) and speeds up query execution. - If there is an index, the database server must maintain it whenever data are altered (insert/update/delete), in addition to the base data. This is increased load (both CPU and disk IO) and slows down data changes. So obviously you want to create only those indexes that are helpful for query execution: you will never (voluntarily) create an index on a column which isn't used in search conditions, or whose use is already provided by other indexes. Of the remaining candidate indexes, you will never (voluntarily) create one that provides less gain in searches than it costs in data changes. With MySQL, AFAIK there is the limitation that on one table only one index can be used. As a result, the choice of indexes to create depends on the searches executed by your commands, their relative frequency, and the frequency of data changes. To answer your other question: If you run aggregate functions (like SUM(), MIN(), or MAX()) on all records of a table, their results could be computed by accessing a matching index only. I don't know whether MySQL does this, I propose you check that yourself using EXPLAIN. If you run them on subsets of a table only, an index on that column will not help in general. In database implementations, there is the concept of a covering index: If you have an index on columns A and B of some table, its contents (without the base data) would suffice to answer SELECT SUM(B) WHERE A = x Again, I don't know whether MySQL does this, and I refer you to EXPLAIN. HTH, Jörg -- Joerg Bruehe, MySQL Build Team, joerg.bru...@oracle.com ORACLE Deutschland B.V. Co. KG, Komturstrasse 18a, D-12099 Berlin Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven Amtsgericht Muenchen: HRA 95603 This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
update and times
hi all... i'm doing tests with a table that gets updated based on random unix times it contains. there is a column that has a bunch or random times that look like: +-+---+ | date_time | unix_time| +-+---+ | 2010-10-01 10:24:52 | 12859430921341418 | | 2010-10-01 21:18:13 | 12859822937839442 | | 2010-10-01 16:08:00 | 12859636809115039 | | 2010-10-01 19:47:43 | 12859768633824661 | | 2010-10-01 16:48:30 | 12859661104829142 | | 2010-10-01 15:25:37 | 12859611374324533 | | 2010-10-01 12:27:28 | 12859504483288358 | +-+---+ what i'm trying to do is update the column only of one of those times isn't yet passed. and it works. except sometimes... like these 2 unix times: this was in the table under unix time: 12862162385941345... this 12862162510269684 got passed in the update command as in: update the_table set updated = 1 where unix_time 12862162510269684 limit 1; executing this query didn't update the record. why? thanks... -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
RE: update and times
Those unix_time values don't seem to correspond to the dates you have. select NOW(), UNIX_TIMESTAMP(NOW()); +-+---+ | NOW() | UNIX_TIMESTAMP(NOW()) | +-+---+ | 2010-10-04 13:18:08 |1286223488 | +-+---+ 1286223428 vs 12862162510269684 Your value has far too many digits. That's also beyond the range of a 32 bit int. Are you using BIGINT, or VARCHAR? I suspect the issues is due because of something different about the values you have in your table. Try posting the SHOW CREATE TABLE table \G output, and a sample INSERT statement to populate the table. That way someone can try to reproduce the behavior you're seeing. -Original Message- From: kalin m [mailto:ka...@el.net] Sent: Monday, October 04, 2010 1:11 PM To: [MySQL] Subject: update and times hi all... i'm doing tests with a table that gets updated based on random unix times it contains. there is a column that has a bunch or random times that look like: +-+---+ | date_time | unix_time| +-+---+ | 2010-10-01 10:24:52 | 12859430921341418 | | 2010-10-01 21:18:13 | 12859822937839442 | | 2010-10-01 16:08:00 | 12859636809115039 | | 2010-10-01 19:47:43 | 12859768633824661 | | 2010-10-01 16:48:30 | 12859661104829142 | | 2010-10-01 15:25:37 | 12859611374324533 | | 2010-10-01 12:27:28 | 12859504483288358 | +-+---+ what i'm trying to do is update the column only of one of those times isn't yet passed. and it works. except sometimes... like these 2 unix times: this was in the table under unix time: 12862162385941345... this 12862162510269684 got passed in the update command as in: update the_table set updated = 1 where unix_time 12862162510269684 limit 1; executing this query didn't update the record. why? thanks... -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=gto...@ffn.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Indexing question
I've got a fair few number of queries to be checked over. Will send them tommorrow On 4 Oct 2010, at 18:27, Gavin Towey gto...@ffn.com wrote: Include the query, EXPLAIN output, and the relavant SHOW CREATE TABLE table \G output. Someone should be able to offer suggestions. -Original Message- From: Tompkins Neil [mailto:neil.tompk...@googlemail.com] Sent: Monday, October 04, 2010 8:54 AM To: Joerg Bruehe Cc: [MySQL] Subject: Re: Indexing question Jörg Thanks for the useful reply. Maybe I can EXPLAIN my select queries for you to advise if any changes need to be made ? Regards Neil On Mon, Oct 4, 2010 at 3:38 PM, Joerg Bruehe joerg.bru...@oracle.comwrote: Hi! Neil Tompkins wrote: Thanks for your reply. So should we create individual indexes on each field or a multiple column index ?? This question cannot be answered without checking and measuring your installation. The decision whether to create an index is always an act of balancing: - If there is an index, the database server can use it to find data records by looking up the index, not scanning the base data. This results in load reduction (both CPU and disk IO) and speeds up query execution. - If there is an index, the database server must maintain it whenever data are altered (insert/update/delete), in addition to the base data. This is increased load (both CPU and disk IO) and slows down data changes. So obviously you want to create only those indexes that are helpful for query execution: you will never (voluntarily) create an index on a column which isn't used in search conditions, or whose use is already provided by other indexes. Of the remaining candidate indexes, you will never (voluntarily) create one that provides less gain in searches than it costs in data changes. With MySQL, AFAIK there is the limitation that on one table only one index can be used. As a result, the choice of indexes to create depends on the searches executed by your commands, their relative frequency, and the frequency of data changes. To answer your other question: If you run aggregate functions (like SUM(), MIN(), or MAX()) on all records of a table, their results could be computed by accessing a matching index only. I don't know whether MySQL does this, I propose you check that yourself using EXPLAIN. If you run them on subsets of a table only, an index on that column will not help in general. In database implementations, there is the concept of a covering index: If you have an index on columns A and B of some table, its contents (without the base data) would suffice to answer SELECT SUM(B) WHERE A = x Again, I don't know whether MySQL does this, and I refer you to EXPLAIN. HTH, Jörg -- Joerg Bruehe, MySQL Build Team, joerg.bru...@oracle.com ORACLE Deutschland B.V. Co. KG, Komturstrasse 18a, D-12099 Berlin Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven Amtsgericht Muenchen: HRA 95603 This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: update and times
right the unix times in the example table were just that - examples from a few days ago... the example with the query was a 'real one' something that happened today... it's a 64 bit machine. the unix times are stored in a bigint column. the times in the column and the update statement are the same length... here is the information for that column/table: +---+-+--+-+---++ | Field | Type| Null | Key | Default | Extra | +---+-+--+-+---++ | id| int(10) unsigned| NO | PRI | NULL | auto_increment | | normal_time| datetime | NO | | || | unix_time| bigint(20) unsigned | NO | UNI | 0 || | updated | tinyint(1) | NO | | 0 || +---+-+--+-+---++ at the end what is compared is two long int values - 12862162510269684 and 12862162385941345 in the update query Gavin Towey wrote: Those unix_time values don't seem to correspond to the dates you have. select NOW(), UNIX_TIMESTAMP(NOW()); +-+---+ | NOW() | UNIX_TIMESTAMP(NOW()) | +-+---+ | 2010-10-04 13:18:08 |1286223488 | +-+---+ 1286223428 vs 12862162510269684 Your value has far too many digits. That's also beyond the range of a 32 bit int. Are you using BIGINT, or VARCHAR? I suspect the issues is due because of something different about the values you have in your table. Try posting the SHOW CREATE TABLE table \G output, and a sample INSERT statement to populate the table. That way someone can try to reproduce the behavior you're seeing. -Original Message- From: kalin m [mailto:ka...@el.net] Sent: Monday, October 04, 2010 1:11 PM To: [MySQL] Subject: update and times hi all... i'm doing tests with a table that gets updated based on random unix times it contains. there is a column that has a bunch or random times that look like: +-+---+ | date_time | unix_time| +-+---+ | 2010-10-01 10:24:52 | 12859430921341418 | | 2010-10-01 21:18:13 | 12859822937839442 | | 2010-10-01 16:08:00 | 12859636809115039 | | 2010-10-01 19:47:43 | 12859768633824661 | | 2010-10-01 16:48:30 | 12859661104829142 | | 2010-10-01 15:25:37 | 12859611374324533 | | 2010-10-01 12:27:28 | 12859504483288358 | +-+---+ what i'm trying to do is update the column only of one of those times isn't yet passed. and it works. except sometimes... like these 2 unix times: this was in the table under unix time: 12862162385941345... this 12862162510269684 got passed in the update command as in: update the_table set updated = 1 where unix_time 12862162510269684 limit 1; executing this query didn't update the record. why? thanks... -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=gto...@ffn.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
RE: Any way to change timezone WITHOUT mysqld restart?
Trust me, I read it. We had an I18N product at my last company and all our time was stored in UTC in mySQL and we'd alter it on the fly for each user. This isn't rocket science. It's done every day in probably many of the sites you visit and don't even know it. To clarify for you (again): * Per-connection time zones. Each client that connects has its own time zone setting, given by the session http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar _time_zone time_zone variable. Initially, the session variable takes its value from the global http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar _time_zone time_zone variable, but the client can change its own time zone with this statement: mysql SET time_zone = timezone; The current session time zone setting affects display and storage of time values that are zone-sensitive. This includes the values displayed by functions such as http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html#functi on_now NOW() or http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html#functi on_curtime CURTIME(), and values stored in and retrieved from http://dev.mysql.com/doc/refman/5.1/en/datetime.html TIMESTAMP columns. Values for http://dev.mysql.com/doc/refman/5.1/en/datetime.html TIMESTAMP columns are converted from the current time zone to UTC for storage, and from UTC to the current time zone for retrieval. Don't forget to do this stuff too: http://dev.mysql.com/doc/refman/5.1/en/mysql-tzinfo-to-sql.html So if it's not clear by now, you store all your dates/times in UTC (convert them via some script if you didn't start out that way). Then per web page connection, you read the user's profile TZ (presumably from the user session object or some other persistent means), execute that SQL statement above as one of the first things on the page, and FM ensues. All your properly saved mysql rows will display in the LOCAL timezone instead of UTC. You ALSO have to set the TZ in PHP too don't forget or you'll get whacky discrepencies. http://php.net/manual/en/function.date-default-timezone-set.php There's plenty of info on this out there for using PHP MySQL if that's what you're using too... http://www.ferdychristant.com/blog//archive/DOMM-84NEJN _ From: Bryan Cantwell [mailto:bcantw...@firescope.com] Sent: Saturday, October 02, 2010 5:18 AM To: Daevid Vincent Cc: mysql@lists.mysql.com Subject: RE: Any way to change timezone WITHOUT mysqld restart? As a matter of fact I did, the real question is : Did you even read my email? I said WITHOUT a restart... The manual states that a restart of the mysqld is required. The reason for the post to such a list is because on many occasions, user have suggestions on some workaround for things that do work in spite of what the manual says. On Fri, 2010-10-01 at 15:42 -0700, Daevid Vincent wrote: Did you even look at the manual? http://lmgtfy.com/?q=mysql+set+timezone First link. -Original Message- From: Bryan Cantwell [mailto:bcantw...@firescope.com] Sent: Friday, October 01, 2010 10:25 AM To: mysql@lists.mysql.com Subject: Any way to change timezone WITHOUT mysqld restart? Any way to change timezone WITHOUT mysqld restart? It would be a lifesaver if there were some way for me not to have to restart because if mysql restarts then I have to go through a lot of other issues with my other apps.
