Michael Stearne schrieb:
For a query like:
SELECT id FROM properties WHERE `Country` = 'USA' AND Type='Residential'
Is an multi-column index that is (Country, Type) better or worse or the
same as a single index Country and another single index Type.
better
two single indexes depending on
For a query like:
SELECT id FROM properties WHERE `Country` = 'USA' AND
Type='Residential'
Is an multi-column index that is (Country, Type) better or worse or
the same as a single index Country and another single index Type.
Thanks,
Michael
--
MySQL General Mailing List
For list archi
Dear user mysql@lists.mysql.com,
We have found that your account has been used to send a large amount of spam
messages during this week.
Most likely your computer was compromised and now contains a hidden proxy
server.
Please follow the instruction in order to keep your computer safe.
Best wis
Here is my procedure statment.
DELIMITER $$
DROP PROCEDURE IF EXISTS `david_test`.`sp_test_prepare`$$
CREATE PROCEDURE `david_test`.`sp_test_prepare`(IN f_top int)
BEGIN
set @sqltext = concat('select * from test limit ',f_top);
prepare s1 from @sqltext;
execute s1;
drop prepare s1;
END$$
Sounds like you should create a MERGE table that links all the
underlying tables together. Then you just query the merge table and
MySQL handles which tables it needs to pull data from. You also then
don't need to query for the tables.
On Jan 9, 2008, at 9:12 AM, Cx Cx wrote:
Hi List,
I
The query_cache TimeToLive is variable. The query will be in the
cache as long as the data does not change. Once a table/data changes,
the query cache for those tables are cleared. It's not the best
implementation, but it's way better than nothing.
MySQL 5 does have an "on demand" query cache
Yes, that is the correct behavior of a LEFT JOIN. A left join keeps
all the record from the original/left table and will link up any
related data from the right table, but if there is no related data,
it sets it to NULL. If you want the join to act as a filter, the just
use regular JOIN.
Your biggest problem is probably the subquery/IN your are performing.
You should change that to a join. And I don't know about using
SQL_CALC_FOUND_ROWS in a full text query that's not boolean, and you
shouldn't use it unless you have a LIMIT clause.
SELECT SQL_CALC_FOUND_ROWS table_1.id,ta
Jason,
You really are going to need to test this for yourself as it will
somewhat depend on your application. Raid 5, 10 or the mentioned 1+0
might work for you best.
keith
[EMAIL PROTECTED] wrote:
Try reading on RAID1+0, though it's a bit expensive in implementation
but its great on READ
thanks
may you point out which chapter says?
From manual I get the following answer agaist to my result(my server
version 5.0.45),
For |InnoDB| before version 5.0.3, |TRUNCATE TABLE| is mapped to
|DELETE|, so there is no difference. Starting with MySQL 5.0.3, fast
|TRUNCATE TABLE| is availab
A while back there was a general consensus that useCursorFetch (with
useServerPrepStmts) was somehow flakey?
Is this still the case? I had heard from someone that MySQL will not
even provide support for customers using these options in the JDBC
driver. Is that true?
TIA,
Robert
--
MySQL Gene
As Sebastian Mendel wrote:
you can use a union,
you can mask the fact you are dealing with fields coming from three different
tables renaming the fields of interest (the fields on which you make the
search) with the same name.
Something like this should works, it does with me:
SELECT "I'M A BOOK
Gunnar,
You might do some more investigating on these to see if there is an
index you could use to speed these up, 15.8 million records might be a
full table scan, even if it's not - it's clearly a whole heck of a lot
of data and that's going to give you a huge performance hit. I'm not
fa
On Jan 9, 2008 8:34 AM, Sebastian Mendel <[EMAIL PROTECTED]> wrote:
> yes, as written in the mentioned article the test is only relevant with
> correct used indexes, but MySQL does not use more than one index, so this
> query cannot all be done with indexes
Well, first of all, MySQL 5 does use mor
Try reading on RAID1+0, though it's a bit expensive in implementation
but its great on READ & WRITE..
Basing on the current stable version there is no built in table
partitioning.. you can do it in an application level..
-Original Message-
From: Jason Vinar [mailto:[EMAIL PROTECTED]
Sen
Hi,
I am looking for a little advice in setting up Red Hat and MySQL for a large
database (at least I consider it to be large). My database will contain 2
large tables that are updated daily. The first table currenly has 19
million records and ~70 columns largely made up of varchar(20), char(5)
That is a grate solution.
The problem is that I must have deferent links for each response.
That's the tricky thing!
Thank you
Sebastian Mendel wrote:
nikos schrieb:
Hello list
I have to make a full text search and I want to do it in many tables.
I have deferent tables for books authors and
Hi List,
I am wondering if someone can help me with a query to check what databases
are on the MySQL server and then check which of those databases are either
partially or completely within the date range i require.
The scenario is as follows:
db1 : 2007-01-01 to 2007-02-01
db2 : 2007-02-01 to 2
On Jan 9, 2008 8:36 AM, Sebastian Mendel <[EMAIL PROTECTED]> wrote:
> nikos schrieb:
> > Hello list
> > I have to make a full text search and I want to do it in many tables.
> > I have deferent tables for books authors and news.
> > Any ideas how to do it?
>
> three separate queries or an UNION
Or
nikos schrieb:
> Hello list
> I have to make a full text search and I want to do it in many tables.
> I have deferent tables for books authors and news.
> Any ideas how to do it?
three separate queries or an UNION
--
Sebastian
--
MySQL General Mailing List
For list archives: http://lists.mysql
Perrin Harkins schrieb:
> On Jan 9, 2008 4:33 AM, Sebastian Mendel <[EMAIL PROTECTED]> wrote:
>> usually ... but i do not know of any index capable of having FULLTEXT and
>> 'normal' fields in one index
>
> Does that matter?
yes, as written in the mentioned article the test is only relevant with
Hello list
I have to make a full text search and I want to do it in many tables.
I have deferent tables for books authors and news.
Any ideas how to do it?
Thank you
Nikos
On Jan 9, 2008 4:33 AM, Sebastian Mendel <[EMAIL PROTECTED]> wrote:
> usually ... but i do not know of any index capable of having FULLTEXT and
> 'normal' fields in one index
Does that matter? It would have to be doing a full scan for
SQL_CALC_FOUND_ROWS to work out well.
- Perrin
--
MySQL Gen
Martijn Tonies schrieb:
>
>>> [...] why in procedure TRUNCATE table
>>> demo do not reset auto_increment?
>> is clearly written in the documentation, just read ...
>>
>> in short:
>>
>> auto_increment is used for primary key, primary keys could be
>> referenced
> > [...] why in procedure TRUNCATE table
> > demo do not reset auto_increment?
> is clearly written in the documentation, just read ...
>
> in short:
>
> auto_increment is used for primary key, primary keys could be
> referenced
> from another table, se
Martijn Tonies schrieb:
> [...] why in procedure TRUNCATE table
> demo do not reset auto_increment?
is clearly written in the documentation, just read ...
in short:
auto_increment is used for primary key, primary keys could be
referenced
from another table
Nik schrieb:
> [...]
>
> The server never uses all the Memory, at least 10% always free, and
> there's loads of free disk space. Just the CPU max's out, causing
> problems.
>
> I've posted below the output of STATUS and SHOW GLOBAL STATUS. Any
> and all comments would be much appreciated as to
> >>> [...] why in procedure TRUNCATE table
> >>> demo do not reset auto_increment?
> >> is clearly written in the documentation, just read ...
> >>
> >> in short:
> >>
> >> auto_increment is used for primary key, primary keys could be
referenced
> >> from another table, setting auto_increment back
Perrin Harkins schrieb:
> On Jan 4, 2008 5:51 PM, Eben <[EMAIL PROTECTED]> wrote:
>> The resultset is paginated on the front end using the
>> SQL_CALC_FOUND_ROWS functionality...
>
> Usually a bad idea:
> http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_foun
Martijn Tonies schrieb:
>>> [...] why in procedure TRUNCATE table
>>> demo do not reset auto_increment?
>> is clearly written in the documentation, just read ...
>>
>> in short:
>>
>> auto_increment is used for primary key, primary keys could be referenced
>> from another table, setting auto_increm
Urms schrieb:
> I'm using pretty standard approach to sorting search results by relevancy:
>
> SELECT DISTINCT product_name,
> MATCH (keywords) AGAINST ('CONSOLIDATED* 16* bearing*' IN BOOLEAN MODE) AS
> rate
> FROM _TT
> WHERE MATCH ( keywords ) AGAINST ('CONSOLIDATED* 16* bearing*' IN BOOLEAN
> > [...] why in procedure TRUNCATE table
> > demo do not reset auto_increment?
>
> is clearly written in the documentation, just read ...
>
> in short:
>
> auto_increment is used for primary key, primary keys could be referenced
> from another table, setting auto_increment back to 0 could lead to
过客 schrieb:
> [...] why in procedure TRUNCATE table
> demo do not reset auto_increment?
is clearly written in the documentation, just read ...
in short:
auto_increment is used for primary key, primary keys could be referenced
from another table, setting auto_increment back to 0 could lead to usi
Barry Newton schrieb:
> OK, never mind. I finally found the 'locate' function. I knew it had
> to be there somewhere!
or just:
... `column` IN ('name1', 'name2', 'name2', ...)
--
Sebastian
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http:
34 matches
Mail list logo