Hello MySQL Community,
Last Friday I changed /etc/mysql/my.cnf file (at server) accidentally.
I set the variable innodb_data_file_path to ibdata1:100M
Then I realized that I changed the server copy. Then to get the original value
I issued the query :
SHOW VARIABLES LIKE
No, this is in and of itself safe. I didn't realise you could change the
InnoDB datafiles on the fly, though - thanks for that hint :-)
MySQL will never write the config file itself, so you're not at risk of
conflict there. You are at risk of putting something in the configfile which
messes up
I'm redesigning some software that's been in use since 2002. I'll be working
with databases that will start small and grow along the way.
In the old format, data would come to us in mega-big text files that had to be
parsed and manipulated and so on with Perl to remove crap and finally
I'm not sure I understand exactly what you mean, but I think you just need to
keep a timestamp associated with each row as it is inserted, put an index on
it, then you can select new data just by using the appropriate time range.
Also, if you're parsing files into tab delimited format, you
On Nov 8, 2010, at 1:23 PM, Gavin Towey wrote:
I'm not sure I understand exactly what you mean, but I think you just need to
keep a timestamp associated with each row as it is inserted, put an index on
it, then you can select new data just by using the appropriate time range.
But won't
I have a client that asked me to look into a situation where they were
seeing different behavior with the same data and same sql on 2
different servers.
The have some sql that was comparing a double to a varchar in a where
clause - something like this:
where (doubleCol varcharCol and some other
I know I can strip off the trailing zeros from the varchar, but there
must be a generic way to cast these so they compare properly as
numbers.
Cast() may happen to fix some rounding errors, but the only way to be
sure of getting rid of such rounding errors in float or double values is
to
On Mon, Nov 8, 2010 at 1:01 PM, Michael Satterwhite mich...@weblore.com wrote:
While I don't know why the behavior changed, the comparison of floating point
values has been an issue since the day computers were created. In the last 10
- 15 years, the comparisons have worked better, but it's
But won't that take just as long as any other queries? Or will it be
speeded up because all the matching records would be adjacent to each other
-- like all at the end?
You can order the result data set by timestamp in descending order, so the
latest will come up first, i.e., LIFO.
The two different versions of MySQL might perform the calculations in a
slightly different order.
By the way, it isn't just comparing numbers that can cause misleading results.
Consider the following.
100 + 1.5 + 7 - 100
What is the result of that calculation?
It depends
-Original Message-
From: vegiv...@gmail.com [mailto:vegiv...@gmail.com] On
Behalf Of Johan De Meersman
Sent: Thursday, November 04, 2010 2:26 AM
To: jcbo...@yahoo.com
Cc: MySQL
Subject: Re: Death of MySQL popularity?
You may want to read that again, but with your glasses on :-)
I think Jorge Bruehe already has weighed in. That is about as direct
as you are likely to hear unless you have Larry Ellison on facebook.
- michael dykman
On Mon, Nov 8, 2010 at 4:41 PM, Daevid Vincent dae...@daevid.com wrote:
-Original Message-
From: vegiv...@gmail.com
If you are selecting records within a certain time range that is a subset of
the entire set of data, then indexes which use the timestamp column will be
fine.
More generally: create appropriate indexes to optimize queries.
Although typically, you should design the database to be correct first,
I was a MySQL Sales Engineer up til a few weeks ago. I spent 6+ year at
MySQL. MySQL Classic never ever had InnoDB in it. Actually, the reason
for the existence of MySQL Classic was just that: MySQL without InnoDB
for OEMs.
If you wanted a non-GPL MySQL, you had to pay for it. And if MySQL
Hello,
I have a query below:
mysql select * from ip_test where 3061579775 between startNum and endNum;
+++-+--+--++
| startNum | endNum | country | province | city | isp|
Good day all
Maybe someone can assist me here as I am not sure where to get this
information from and I need this for a proposed environment for a
client.
1. The client will have 2 new machines, had a look at the specs and
it is fairly good considering it will be dedicated to MySQL.
Indexes typically only work on the left-hand-side. Rewrite as
select * from ip_test where startNum = 3061579775 and endNum = 3061579775;
Magic will happen.
2010/11/9 wroxdb wro...@gmail.com
Hello,
I have a query below:
mysql select * from ip_test where 3061579775 between startNum and
17 matches
Mail list logo
