To go along with what Rick is saying, this link might help you:
http://dba.stackexchange.com/questions/10467/how-to-convert-control-characters-in-mysql-from-latin1-to-utf-8
I remember doing a bunch of converting HEX() control characters (such as an
apostrophe copied from a Word document) before
2012/09/24 16:28 -0700, Mark Phillips
I have a table, Articles, of news articles (in English) with three text
columns for the intro, body, and caption. The data came from a web page,
and the content was cut and pasted from other sources. I am finding that
there are some non utf-8 characte
I try to figure out something observing the stats with SHOW STATUS. There are
some reads, writes, etc that tell something about what is going on.
Looking just at the file sizes is likely going to not tell much about the
progress.
If there is a better way to monitor this progress, I would li
Am 27.09.2012 23:15, schrieb Larry Martell:
>> Indexes are slowing this down. your calculation of 79 hours should be
>> correct, only if there are no unique indexes, otherwise this will slow down
>> more as the data increases.
>
> It is what it is - there's no free lunch - dropping the indexes, do
On Thu, Sep 27, 2012 at 3:02 PM, Akshay Suryavanshi
wrote:
> Hi,
>
> 22 indexes are simply too many, assuming they are not composite, which means
> you already have a very large table.
Yeah, I agree the table has too many columns and too many indexes. I
didn't design it, and I have no control ove
Hi,
22 indexes are simply too many, assuming they are not composite, which
means you already have a very large table. Secondly the most important
bottleneck is shown by the inserts/sec, only 405 inserts is very very slow.
This could take ages to complete. And the 405 inserts/sec are averages
calcu
On Thu, Sep 27, 2012 at 2:37 PM, Akshay Suryavanshi
wrote:
> Hi,
>
> The alter taking such a long time, could be due to composite indexes on the
> table.
There are 22 indexes on the table, but none are composites.
> we understand the table is big but not so big to take such a long
> time. Also w
Hi,
The alter taking such a long time, could be due to composite indexes on the
table. we understand the table is big but not so big to take such a long
time. Also we can get a hold of the process looking at the disk space
consumed. Usually a tmp table created in data directory would also give a
g
I read that here:
http://gabrielcain.com/blog/2009/08/05/mysql-alter-table-and-how-to-observe-progress/comment-page-1/
On Thu, Sep 27, 2012 at 2:26 PM, Rick James wrote:
> Isn't ALTER a DDL, not DML? So I don't think you would find anything in undo
> logs.
>
>> -Original Message-
>> Fr
Isn't ALTER a DDL, not DML? So I don't think you would find anything in undo
logs.
> -Original Message-
> From: Larry Martell [mailto:larry.mart...@gmail.com]
> Sent: Thursday, September 27, 2012 1:20 PM
> To: Rick James
> Cc: mysql mailing list
> Subject: checking progress of alter tabl
So we changed the table from MyISAM to InnoDB. I read that the 'undo
log entries' shown in 'show engine innodb status' would correspond to
the number of rows that have been operated on throughout the process
of the ALTER. The table we're altering has 115,096,205 rows, and the
alter's been running f
Long term solution:
Switch to XtraDB (InnoDB), and use Percona's online alter.
If you do switch engines, take note of issues:
http://kb.askmonty.org/en/converting-tables-from-myisam-to-innodb/
> -Original Message-
> From: Reindl Harald [mailto:h.rei...@thelounge.net]
> Sent: Monday, June
12 matches
Mail list logo
