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
> Hello,
>
> I have a query below:
>
> mysql> select * from ip_test where 3061579775 between startNum and endNum;
> +-
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. Th
Hello,
I have a query below:
mysql> select * from ip_test where 3061579775 between startNum and endNum;
+++-+--+--++
| startNum | endNum | country | province | city | isp|
+++-+--+--+
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
wa
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 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 wrote:
>> -Original Message-
>> From: vegiv...@gmail.com [mailto:vegiv...@gmail.com
> -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
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 upon
>> 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.
-Origi
On Mon, Nov 8, 2010 at 1:01 PM, Michael Satterwhite 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 still an issue. The
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 chang
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
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'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 don
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 produc
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 you
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 'innodb_data_file_path
17 matches
Mail list logo
