On 7/23/07, mos [EMAIL PROTECTED] wrote:
Load data will of course be much faster. However to obtain the maximum
speed you need to load the data to an empty table, because then MySQL will
load the data without updating the index for every row that's added, and
will instead rebuild the index only
On 7/19/07, John Comerford [EMAIL PROTECTED] wrote:
I am in the process of putting together a web application. I have
decided to add a 'RowId' field to all my tables and assign it a unique
number so that I use it to retrieve data. In concept this number might
be passed back to the server as
On 7/12/07, Jerry Schwartz [EMAIL PROTECTED] wrote:
I believe this query
will do it, but can it be redone without the sub-query by using JOINs?
Yes, use a LEFT JOIN.
Would that be more efficient?
Yes.
SELECT prod.prod_num, price.prod_price
FROM prod JOIN price
WHERE prod.prod_id =
On 7/12/07, Jerry Schwartz [EMAIL PROTECTED] wrote:
Since the rows is identical except for the last bit, where mine is 4 and
yours is 2, does that mean yours is roughly more efficient by a 2:1 ratio?
For the most part, MySQL will do better with LEFT JOIN than an IN
subquery. You can read all
On 7/12/07, Jerry Schwartz [EMAIL PROTECTED] wrote:
I think that will give me one record for every price that is not Yen, so if
a product has a price in USD and a price in GBP it will show up twice.
That would happen if you removed the 'USD' condition from the first
JOIN. Like I said, I'm not
On 7/12/07, mos [EMAIL PROTECTED] wrote:
BTW, joins will work faster if you load one or more tables in a Memory
table before you do the join.
Well, if your tables are so small that you can load them entirely into
memory, it probably doesn't matter how you code the query.
- Perrin
--
MySQL
On 6/29/07, Rich Brant [EMAIL PROTECTED] wrote:
Hello all. I'm looking for help with the query below. Is there anyway
to prevent the temporary and filesort?
The filesort is caused by either the ORDER BY or the GROUP BY. There
are sections in the manual about how to get it to use indexes for
On 6/21/07, Guillermo [EMAIL PROTECTED] wrote:
Hello,
I have a query that i could do in 2 diferent ways...i want to know wich one
is recomended:
* Select T1.field1,T1.field2, (select sum(T2.field4) from Table2 T2 where
T2.field1 = T1.field1) from Table1 T1
or
* Select
On 6/21/07, CA Lists [EMAIL PROTECTED] wrote:
Note that uid 12880 is now AFTER 12878, which is its parent.
Sounds like you want ORDER BY COALESCE(parent, uid) DESC.
- Perrin
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
I have a large InnoDB table which I want to add a TIMESTAMP column to
and a new index. It's actually a few tables and in some cases I only
want to index the new column but in others it's a multi-key index with
the new column and another column.
The problem is that this is taking many, many
On 6/7/07, Cory Robin [EMAIL PROTECTED] wrote:
The issue I have is that the ratio of queries on old vs.
new data is like 1:10. And searches would be MUCH
faster if I could force my queries that are looking at
current or future data to use an index that ONLY had that
information in them..
Hi,
I'm working on a rewrite of a batch process that operates on a large
InnoDB database. In the past, it would process the entire database
every night, but now the size of the data is making that impossible,
and there is a desire for the process to operate in near real-time, so
I'm rewriting
On 5/30/07, Dan Buettner [EMAIL PROTECTED] wrote:
#1 - it's not a good approach to hope your database keeps up. There are
fairly common situations that can come up where you never know how long
something will take - unusually high traffic, table check and repair, a bulk
load into the same or
101 - 113 of 113 matches
Mail list logo
