Tracking Forums, Newsgroups, Maling Lists
Home Scripts Tutorials Tracker Forums
 
  HOME    TRACKER    MYSQL




Searching And Indexes


I have a fair sized table now (1,955,041 rows) and it currently has two indexes:
PRIMARY is the ID number
and
Keywords is a FULLTEXT index of the Keywords column (Text).

In my first query type I also check two other fields: Disabled and Toplevel

SELECT * FROM files WHERE Disabled='0' AND TopLevel='clipart' AND MATCH (Keywords) AGAINST ('+tree' IN BOOLEAN MODE) ORDER by ID;

In my first query type I do not have keywords but am rather checking to see if an image belongs to a particular category like so:

SELECT * FROM files WHERE Disabled='0' AND TopLevel='clipart' AND (Category='Food' OR Category2='Food' OR Category3='Food' OR Category4='Food') ORDER by ID

My question is, are there any other indexes (or anything else) that I can do that will speed up the results?

+----------------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------+------------------+------+-----+---------+----------------+
| ID | int(20) unsigned | | PRI | NULL | auto_increment |
| Disabled | char(2) | | | 0 | |
| TopLevel | varchar(50) | | | | |
| Keywords | text | | | | |
| Category | varchar(100) | | | | |
| Category2 | varchar(20) | | | | |
| Category3 | varchar(20) | | | | |
| Category4 | varchar(20) | | | | |




View Complete Forum Thread with Replies

See Related Forum Messages: Follow the Links Below to View Complete Thread
Use Of INDEXES
I have a tiny question about indexes... Why we use indexes,what is the purpose of indexes, what are the benefits of indexes...

What Are Indexes?
What exactly are indexes?

are they like Foriegn Keys?

How do you make Foriegn Keys?

How would you go about specifying the primary key link to the foriegn key?

whats a good situation when indexes are most needed?

Use Indexes?
My table has some indexes declared. How I can use them in the select queries in order to achieve better performance?

Indexes
I have a table which has a range of values all with unique id's. The primary key is an auto-increment field.

Imagine: 5 records (1000, 1001, 1002, 1003, 1004)

I have a query:

SELECT * FROM mytable WHERE id IN (1002,1004,1001,1000, 1003)

I want the order of the returned records to be in order in which the id's are specified using the IN keyword.

The result is always returned in primary key order and not the order I specify with IN.

Indexes
I want to create a index to help the following statement run faster, can anyone suggest which would be the best index to create:

select * from profile, album, movie, book, contact
where profile.album = album.albumid
and profile.movie = movie.movieid
and profile.book = book.bookid
and profile.username=contact.username
and profile.sex != "male"
and profile.searchsex != "female"
and profile.relationship != "dating"
and photo_validated != "yes";

Also is there a way to see which indexes yo have already created ie. is there a "show indexes" or "desc indexes" statement that will show me all the indexes on a database or table.

Use Of Indexes
I read up about using 'index' but am not clear about it at all. Is there some link somewhere that explains this with an example so I can see how its useful?

Best Use Of Indexes
I have a situation where I am doing the following:

Example keys:

key1
key2
key3

Now "key1" is used a lot in WHERE queries with "key2" & "key3"; however they are not used all together at once.. "key1" is only used with 2 & 3 seperately.

So I was wondering is it best to create 2 seperate indexes such as:

key1
key2

key1
key3

..or create one such as..

key1
key2
key3

?

I created the two seperate ones, but phpmyadmin is complaining about me having two indexes created for "key1".

Indexes
I'm having some trouble with indexes and I'm pretty confused as to why this is not working. I have a 5GB table with over 2 million entries. I have indexing setup as follows:

KEY `ticketposts3` (`creator`,`staffid`,`dateline`)

I'm trying to run this query:

EXPLAIN SELECT ticketid FROM swticketposts WHERE creator='bob' AND staffid=96 AND dateline BETWEEN 1172988000 AND 1173074400;

and I get:

| 1 | SIMPLE | swticketposts | range | ticketposts3 | ticketposts3 | 10 | NULL | 1 | Using where |

Which means indexing is not used. If i change the query as follows:

EXPLAIN SELECT dateline FROM swticketposts WHERE creator='bob' AND staffid=96 AND dateline BETWEEN 1172988000 AND 1173074400;

It does work and I see:

| 1 | SIMPLE | swticketposts | range | ticketposts3 | ticketposts3 | 10 | NULL | 1 | Using where; Using index |

Any idea why this is happening?

Indexes
I am trying to set up some indexes to help the speed of my queries. In table "poster" I have a column called "color" that is a varchar(3) and contains values of either "yes" or "no".

I created an index on color (ALTER TABLE poster ADD INDEX color (color);) but for some reason the cardinality is only 1, not 2. When I do EXPLAIN SELECT * FROM poster WHERE color LIKE 'yes'; I get

id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
1 | SIMPLE | poster | ALL | color | NULL | NULL | NULL | 33577 | Using where

but when I do EXPLAIN SELECT * FROM poster WHERE color LIKE 'no'; I get

id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
1 | SIMPLE | poster | range | color | color | 11 | NULL | 5707 | Using where

Why does my color index get used when color LIKE 'no' but not when color LIKE 'yes'? Also, why is the key length 11 when the column is only varchar(3)?

Indexes
I've been over the documentation and am still a bit confused on the most beneficial way to set up indexes in MySQL for certain tables. Imagine I have a table that is used purely for cross-reference, containing 4 columns. A query into this table may involve joining or filtering on anywhere from one to all of these columns. Is it best to:

A. set up one index for each possible combination/arrangement of the columns,
B. set up four indexes, with one column in each, or
C. don't index this table because it's not appropriate.

Indexes
i have a table with about 1.5 million records - it has about 80 columns

up until this point i have always had many indexes and i have to say it is very fast

anyway purely in a development stage i had to create a duplicate of the table and add some more columns, no indexes are defined on the new table.

it works as fast if not faster without any indexes!

am i missing something here?

Two Indexes
I have a DB made up o three tables.
I created a multi-column index called idx on (table1.id, table2.id).
I also would like to create an index idtot on (table1.id,table2.id, table3.id)
and an index idp on (table1.id, table2.id).
First of all I would like to know if this is possible.
If so,
when I make a query like

"select table1.id from table1,table3 where table1.id=table3.id",
MySQL automatically chooses the right index idp to make the search, or
do I have to specify it? (and if so, how?).

Indexes
i have a table (all_data) which has 750,000 rows.
it has a primary key (unique_ref) which is fine.
there is another column (prev_unique_ref) which i would like to add a unique reference to but it is not processing.
there are some null values in the column and the rest are all completely different but documentation i am reading does not to seem to suggest that should be a problem.

Indexes
I'm wading through the waters of "MySQL/PHP Database Applications," and I still cannot get this INDEX malarcky into my head. What exactly is an index? What's a working example that would put it into clear understanding

Indexes
Do you all think I should add indexes to the sortable fields I have available on my site.

Check the links on the upper left corner where it says "sort by".
http://gifdump.com/browse/all/

Indexes
I am looking to add indexes to my database to try and improve performance. Now I heard someone say once that you should add an index to any column that you are planning to filter using in the where part of your statements.
So my question is this, in below is an example i have a table that I use to store reports that are generated by the system (i haven't chosen this especially but it has the core element that i user everywhere else). These core elements and columns that i regally in a where clause have '*' next to them. As such if i was following the advice of were to add indexes, i would probably add one to each of these columns.
Then there are the other three that have '+', which occasionally i conduct a '%%' (wildcard) search on to help me find a cretin report.
given this, plus the index on the primary key almost every table would have an index on it. To me this seems a bit much. So how many is too many?


Indexes
I have a few books on mysql and have succesfully now transferred all my records over from ms access. everything does work ok but it searches are a little slow (even slower than ms access which is why i moved in the first place).
I have 17 tables in the database and it is all in third normal form. I have correct primary keys on all.
I think indexes is the prolem here. I have added a few but i am unsure about how many to add and also about updating them.
Can you please give your advice in terms of how many indexes should be used normally and how easy it is to update them?

Difference In Indexes
What is the difference between these two types of indexes?

ALTER TABLE mytable ADD INDEX ( myfield1 )
ALTER TABLE mytable ADD INDEX ( myfield2 )
and

ALTER TABLE mytable ADD INDEX ( myfield1, myfield2 )
or is there no difference?

More Than 32 Indexes With MyISAM?
I've searched Google every way I know how, and came up with two answers that
refer to MAX_KEY and MI_MAX_KEY, along with a typedef for key_map.

I have the 4.1.1 alpha source (4.0 is no good, because it doesn't support
subqueries).

I changed the two defines in sql/mysql_priv.h and include/myisam.h,
respectively. The typedef for key_map is no longer ulong or ulonglong, but
instead Bitmap(64);

I left that alone.

After compiling, an attempt to create a table with more than 32 indexes
(which I absolutely must have) still shows an error referring to 32 max keys.

What's going on here? I could not find anywhere in the code that generates
that error which doesn't check either or both of the above defines.

So why isn't it working? Is it hard coded somewhere?

ORDER BY - Where Put Indexes
i must sort this way

ORDER BY IF((Katalog_NowaOcena > 0 && Katalog_OcenaIlosc > 0),(Katalog_NowaOcena*Katalog_OcenaWartosc/Katalog_OcenaIlosc),IF(Katalog_NowaOcena > 0,Katalog_NowaOcena,(Katalog_OcenaWartosc/Katalog_OcenaIlosc))) DESC

where i should put indexes to reach max preformance (medium database - 200k records)

Preserving Indexes
I'm using phpMyAdmin for the most part. I notice that the index cardinality
shows up as None in phpMyAdmin for each index I have. If I drop the index
and re-create it, all of the indexes show their correct cardinality. I
don't think phpMyAdmin is at fault because searching on the table before I
fix it is sluggish until afterwards. Is the a command I could run that
would re-index everything after I dump the data into the table? Or what is
going on?

More Than 32 Indexes With MyISAM?
I've searched Google every way I know how, and came up with two answers that
refer to MAX_KEY and MI_MAX_KEY, along with a typedef for key_map.

I have the 4.1.1 alpha source (4.0 is no good, because it doesn't support
subqueries).

I changed the two defines in sql/mysql_priv.h and include/myisam.h,
respectively. The typedef for key_map is no longer ulong or ulonglong, but
instead Bitmap(64);

I left that alone.

After compiling, an attempt to create a table with more than 32 indexes
(which I absolutely must have) still shows an error referring to 32 max keys.

What's going on here? I could not find anywhere in the code that generates
that error which doesn't check either or both of the above defines.

So why isn't it working? Is it hard coded somewhere?

Linking Indexes
I have two tables...

tbl_one
id two_id info_a info_b
tbl_two
id info_c

And what I want to do is link `two_id`, an index to the `id` field in `tbl_two`. Then I basically want to be able to display data (specifically `info_c`) by referring to the `two_id` field. What would be the easiest way to achieve this?

Indexes In MYSQL
Is there any way to know if/when you should set up and use indexes on a MySQL table? A chatroom I created has a post table with the following fields:

id = int(11) (Primary Key)
name = varchar(40)
post = text
timestamp = varchar(20)
trash = smallint(1)
invisible = smallint(1)
ip_address = varchar(20)

The trash and invisible fields are used in WHERE clauses to determine what a user can and cannot see. The timestamp and id fields are used for ordering.

What fields should I create indexes on, if any? I'm looking for a general rule of thumb, so that I can make the necessary indexes on all my SQL tables.

Indexes With Sorting
i've got a table
Id,Name,Status,DateAdded,Rate

So i'd like to select 5 newest records with status = 1

SELECT * FROM Table WHERE Status = 1 ORDER BY DateAdded DESC LIMIT 5

Optimizination Using Indexes
SELECT
`salfldggol`.`ACCNT_CODE`,
`ssrfacc`.`ACCNT_CODE`,
`salfldggol`.`PERIOD`,
`salfldggol`.`AMOUNT`,
`ssrfanv`.`CODE`,
`salfldggol`.`ANAL_T1`,
`ssrfanv`.`CATEGORY`,
`ssrfanv`.`NAME`,
`ssrfacc`.`ACCNT_NAME`,
`ssrfacc`.`SUN_DB`
FROM
`salfldggol` INNER JOIN `ssrfacc` ON `salfldggol`.`ACCNT_CODE` =
`ssrfacc`.`ACCNT_CODE`
INNER JOIN `ssrfanv` ON `salfldggol`.`ANAL_T1` = `ssrfanv`.`CODE`

About Multiples Indexes
is it a good idea to make a multiple primary key with an autoincrement index and another key? or it's better to make a single autoicrement primary key and then another index with this autoincrement index and the another index?

Creating Indexes
I have a doubt on indexes. I need to create some indexes on a series of relations I created with mysql. I have to create a index on the primary key and a index on the foreign key for each table. The problem I found is with tables of this type: I have two columns, both belong to the primary key, and only one is a foreign key. Is it different if I create the indexes this way:

create index primarykey on table(column1, column2);
create index foreignkey on table(column2);

or this way:

create index foreignkey on table(column1);
create index i2 on table(column2);

I mean, is it different to create a index on two columns or creating two indexes each on one column?

Duplicate Indexes
I have this table:

CREATE TABLE `foo` (
`logId` int(10) unsigned NOT NULL auto_increment,
`uid` varchar(64) default NULL,
`activityDate` datetime default NULL,
`activityType` varchar(255) default NULL,
PRIMARY KEY (`logId`),
UNIQUE KEY `noDups` (`uid`,`activityDate`,`activityType`),
KEY `uid` (`uid`),
KEY `activityType` (`activityType`),
KEY `activityDate` (`activityDate`),
) ENGINE=MyISAM DEFAULT CHARSET=utf8

is the index 'uid' a duplicate index, since it is also the first index in 'noDups' ?

Enum Or Indexes
My question is, would there be a significant impact on optimization by removing the enum in favor of other tables.For example, in the table there is a column of type enum to represent the 50 states. Is there any advantage performance-wise to move these 50 states into a table?

Creating Indexes
i have 2 tables, from which i need to select based on an inner join. The join uses 2 columns, surname, and postcode. I am assuming that instead of joining on both columns, i should create a new one that contains both the surname and postcode, and just do the join on the new single column (surname_postcode). My question is, do i need to phsically create a new field in my table, and update it with a concat of the surname and postcode, or am i going about this wrong? Does mysql has built in functionality to deal with this situation at all?

Indexes, Primary Key
I have set up a temperature logging system with ds18s20 one-wire sensors.
In the MySQL database I have a table with four columns - time as timestamp, outside, inside and server temperatures as floats.
A small C program runs the Digitemp ( http://www.digitemp.com ) program every half hour from cron, parses the output and inserts now() and temperatures.
The data is used by a web page, and I mostly select according to timestamp (for example, the last week).Would there be any performance to gain from creating an index on the timestamp? It is already ordered, ascending in the table.
I have not set a primary key on the table either, would that be any advantage?

MySQL Indexes
if the indexes of a table are dynamically updated... in other words, if I have a table updated every minute, do the related indexes are updated as well?

FULLTEXT Indexes
whenever i try to install Minerva, a phpBB2 CMS, i get the error message that the FULLTEXT indexes dont exsist and that it cant create the files. can anybody help me with this?

FULLTEXT Indexes
I know that FULLTEXT indexes actually return meaningful results but I also suspect they add a lot of overhead to the database server.I can't change it for our existing application but for the next major revision I was planning to create a search table that contains all words that get entered into the database (apart from noise words) with an article ID.I think that might get a bit complicated though as it would have to return results and then scan through the text returned to highlight that word? Actually not that hard but is it worth it for performance benefits?

Two FULLTEXT Indexes
I'm building a new database and I will need a search engine for it.
I wonder if it would be ok if the database contains two fulltext
indexes.It's because my database will contain English document and French
document.I would put two FULLTEXT indexes in my table so that way, you could do
your research only on the French document or only on the English ones.
So my question is, would it be better to put the two fulltext index in
one table or do a table for the French articles and a table for the
English articles.

Reset Indexes
How do I reset the indexes on a table?
Because... I assume that with index skips, eg... 4-5-7-8-12... Where stuff got deleted. This code here might become inefficient?


$gotConf = false;
while ($gotConf == false){
$confData = mysql_query("SELECT * FROM confession WHERE id >= (SELECT FLOOR( MAX(id) * RAND()) FROM confession) AND active=1 ORDER BY id LIMIT 1;", $conn) or die ('Confession select failed');
$confInfo = mysql_fetch_array($confData);
if (isset($confInfo[text]{2})){
$gotConf= true;
}
}

Table Indexes
1. is this true that all the fields on which you will be doing search one should make them index?
2. is there a limit to how many index fiedls you can have?
3. i once was geting this error while creating a table "specified key can be max 500"
when i got rid of index it got created sucessfully I don't know why?

MySQL Optimization & Ignored Indexes:
I'm a little confused as to why the following indexes would be ignored? Can someone shed a little light on this?

Simple order by: ........

Foreign Keys & Indexes
I have altered my tables to include foreign keys, but I would like to know if they should appear in those tables?
When I altered the tables to have these foreign keys, I also inserted on update cascade and on delete cascade:-
alter table item add foreign key (id) references name(id)
on update cascade on delete cascade;
How can I test that this works?
Do you also have to index these foreign keys for them to work, if so, how do you alter the table to do this?



Question About Indexes And Joins
I am sure that someone has asked this before here, but I just want to make sure.

TABLE 1 (names)

user_id | username (PRIMARY user_id)

TABLE 2 (links)

owner_id | user_id (PRIMARY owner_id)



SELECT l.owner_id,l.user_id,n.username FROM links l INNER JOIN names n ON l.user_id=n.user_id WHERE l.owner_id=...

OK, in this case the links table is joining with the names table. There is only one index per table (PRIMARY), and when queried they are both used.

BUT does the user_id column in the links table (the one that is being used as the join condition: n.user_id) require an index? By the looks of it, and since it is just a column value that is compared to the other table's user_id value, it doesn't need anything.

Does it require an index?

Multi And Single Indexes
I've got a MyISAM table:

CREATE TABLE student
(
student_id INT UNSIGNED AUTO_INCREMENT NOT NULL,
detail_id INT UNSIGNED NOT NULL,
school_id INT UNSIGNED NOT NULL,
teacher_id INT UNSIGNED NOT NULL,
supplier_id SMALLINT UNSIGNED NOT NULL,
name VARCHAR(30) UNSIGNED NOT NULL,
address VARCHAR(255) NOT NULL,
PRIMARY KEY(student_id),
FOREIGN KEY(detail_id) REFERENCES class(detail_id),
FOREIGN KEY(school_id) REFERENCES school(school_id),
FOREIGN KEY(teacher_id) REFERENCES teacher(teacher_id),
UNIQUE INDEX detail_school_teacher (detail_id, school_id, teacher_id)
)

The main search involves linking the foreign keys and getting data from each table.

I am getting the following warning: UNIQUE and INDEX keys should not both be set for column 'detail_id'

Should I get rid of the UNIQUE INDEX or all the other INDEX keys?

Also I don't think the foreign keys are used with MyISAM tables - but are they at least used as INDEX or should I replace FOREIGN KEY with INDEX?

Adding Indexes Using Php Script
My client's temporary host will not allow access to the database but will allow me to run php script that will alter table and add index on mysql version 4.0.

I want to add indexes on fields in tables that are PRIMARY key fields in related tables. Say table2 has a primary key table2_id and a field called table1_id.

If I wanted to add an index to table2, would I do that this way?

<?
//get connected to db
mysql_query("CREATE UNIQUE INDEX TABLE1_ID on table2 (table1_id)");

?>

Trouble With Indexes And Inserts
Here's the situation(mysql 5.1)
(all the sql commands are below for easy replication)

If I put an index of length shorter than the field it is based on, I can't insert a row into a new table if that row has a value of that field longer than the index but shorter than the field definition. This is probably not a completely accurate description, but I'll show what I mean by a simple sequence.

1.Create two tables. table 1 is the source. table2 will be getting the inserts. table1 has an index (ix_org) which is 10 long, while org, the field it is based on is 30 long.

create table table1 (
name varchar(30),
place smallint,
org varchar(30),
index ix_org (org(10))
) engine = MyISAM;

create table table2 (
name varchar(30),
place smallint,
org varchar(30),
place_total varchar(10)
) engine = MyISAM;

2. Insert some data into table1. Two rows: one row with a "org" field length shorter than 10 and another with a field length longer than 10.

insert into table1 (name, place, org)
values ('Joe',&#395;',&#397;_chars'),
('Fred',&#3910;',&#3913;_characters');

3. now do the inserts

test 1:

insert into table2 select
name as name,
place as place,
org as org,
concat(place,'/', (select max(place) from table1 where org=&#397;_chars')) as place_total
from table1 t1;

Result: all is good. in this case we are joining (in the subquery) on a value of "org" which is less than 10 characters > two rows inserted.


test 2:

(now join in the subquery with field length of org longer than 13)

insert into table2 select
name as name,
place as place,
org as org,
concat(place,'/', (select max(place) from table1 where org=&#3913;_characters')) as place_total
from table1 t1;

Result: does not insert. error "data too long for column org at row1".

Other tests:
* if the length of the index is made the same length as the field, the error doesn't occur.
* if the subquery is not in the insert command, the error doesn't occur.

Utilization Of Indexes Using IN Syntax
The following query does not utilize any indexes:

SELECT * FROM `comic_comments`
WHERE poster_ip IN
(SELECT poster_ip FROM comic_comments WHERE guest_name='TestName' GROUP BY poster_ip)

Even though there is an index on poster_ip. Any clues as to why?

Here are the EXPLAIN results:

id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY comic_comments ALL NULL NULL NULL NULL 50000 Using where
2 DEPENDENT SUBQUERY comic_comments index NULL poster_ip 18 NULL 50000 Using where; Using filesort
Also, if I make a compound index on guest_name and poster_ip, it doesn't really solve the problem. The primary select would still show ref="50000" in that case.

Indexes And Why NOT To Mix Field Types
In a WHERE clause, if you are mixing field types between an INT field and a VARCHAR field, MySQL won't use the otherwise appropriate index! Your indexes essentially become worthless in this case! So when you relate tables, make sure your relate-fields are in INT form instead of VARCHAR form if they are relating to an INT field.

And for so damn long I couldn't figure out why MySQL never used any of my indexes...

Help With Model - Logic & Indexes
I'm designing my first db application (accommodation) and I would like some help with a few things.
Trying to learn too much over a very short period time has proven slightly overwhelming.
Any feedback would be appreciated.

Ok, first of all, I'm using MySQL v. 4.0.26 because that's what my hosting provider provides.

1. I'd be great if I could have some feedback on my db model attached.
Have I overlooked something that might lead to complications?

2. I'm using MyISAM tables because I'll definetely need to be able to search for accommodation names, and maybe for keywords in their description too.
Although I need the search capabilities of MyISAM tables I'm trying to figure out whether transactions are more important due to the fact that the accommodation data is split amongst several tables.
Any ideas? Do you think it'd be better if I combined MyISAM tables with InnoDB tables, or is that going to be a problem?

I'm also thinking of adding "record locking" by creating an extra table with the acc_id of the records that are being edited. If another user selects that particular record while it's locked, he will get a "record being edited" message.
Is this the right way to go about this?

3. What is the best way to index these tables?
For most of the "accommodation entry" tables (right side of model) the acc_id FK can be created as a PK.
That will index it automatically (note: I know that MyISAM doesn't support FKs).

What about the following tables though?
acc_entry
acc_entry_facilities
acc_entry_room_fac
acc_entry_sports
The last 3 tables have 2 columns consisting of 2 FKs. I was thinking that I could just declare both of these as PKs.
The 1st table though has multiple FKs and I'm thinking to follow the same method - and creat all of the FKs as PKs.
Please refer to create.sql file attached for this.
Is this correct?

What about the acc_entry_distances column? Would I benefit from a dirrenent kind of index in order to find i.e.
all accommodation 10m from the beach and 100m from town.

Is the following create statement the right one?



/* I will only need to search for the distance
from town, airport, port, sea and beach */

CREATE TABLE acc_entry_distances (
acc_id TINYINT UNSIGNED NOT NULL,
town CHAR(10) NOT NULL,
airport CHAR(10) NOT NULL,
port CHAR(10) NOT NULL,
village CHAR(10) NOT NULL,
sea CHAR(10) NOT NULL,
beach CHAR(10) NOT NULL,
market CHAR(10) NOT NULL,
pharmacy CHAR(10) NULL,
PRIMARY KEY(acc_id),
INDEX town_index (town, airport, port, sea, beach),
INDEX airport_index (airport, port, sea, beach),
INDEX port_index (port, sea, beach),
INDEX sea_index (sea, beach),
INDEX beach_index (beach)
);

I'm including below some untested queries that I will definetely need to perform:


/* get all 5* "Hotel" records (class_id=5 and type_id=1) */

SELECT *
FROM acc_entry as en,
acc_entry_data as da,
acc_entry_data as di
WHERE en.type_id = 1
AND en.class_id = 5
AND en.acc_id = da.acc_id
AND di.acc_id = en.acc_id;


/* get all Hotel records with a swimming pool, a restaurant
and a gym (type_id=1, fac_id=3, fac_id=5, sport_id=4) */

SELECT *
FROM acc_entry as en,
acc_entry_data as da,
acc_entry_distances as di,
acc_entry_facilities as fa,
acc_entry_sports as sp
WHERE en.type_id = 1

AND en.acc_id = fa.acc_id
AND fa.fac_id = 3
AND fa.fac_id = 5

AND en.acc_id = sp.acc_id
AND sp.sport_id = 4

AND en.acc_id = da.acc_id
AND en.acc_id = di.acc_id;

Help On DB Definition How To Make My Indexes?
I an a complete rookie in DB. I have to build a catalog DB but I am lost in the indexes part. If you look at the attached image I have this composite Primary key made of
conceptoID, divisionID, descripcionID, marcaID, lineaID and seqID also i have an index of those same fields. This is because I have to search somewhere else in the process for data having those fileds.

My first question is how do I have to use the primary key in a SELECT or so statement?My second is Do I really need all those indexes or just the primary key is enogh to search for example WHERE divisionID="whatever"Also I noticed the cardinality of those indexes is zero. Do I have to build each one of them?

Primary Key, Redundant Indexes
I have a question regarding indexes.

I have a table which I normally search on column 1, column 2 independently. Together column 1 and 2 are always unique.

I added and Indext to 1, 2 independently and everything is fine. Then in order to keep the referential integrity I created a Primary Key of column 1,2 and then I got a message that I should not have both PK and indexes on the same table.

Hence my question - does the PK replace the need of the two previous indexes?


Copyright © 2005-08 www.BigResource.com, All rights reserved