What are common indexes?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • robertbrown1971@yahoo.com

    What are common indexes?

    I just inherited a Java application with a fairly complex data model
    that does not yet have any indexes except those on primary keys. It is
    still in development and before I get to do any performance testing I
    want to put some default indexes on it. I realize that this a very
    vague request but it's better than nothing so I want to start with
    those that are generally a good idea and then tune those areas that
    require more fine grained approach. By the way, I'm mostly a Java
    programmer so please forgive my DB ignorance and I thank you for any
    help.

    Since the full schema is quite large I will use a simple example (fully
    cited below my questions). Here is list of indexes that I think would
    be a good idea. If anyone can add to it or comment on my questions I
    would appreciate it.


    1. Index on primary keys in all three tables. My understanding that
    this indexing happens automatically just by declaring that a column is
    a PK.

    ALTER TABLE employees ADD PRIMARY KEY (emp_id);
    ALTER TABLE employee_addres ses ADD PRIMARY KEY (address_id);
    ALTER TABLE departments ADD PRIMARY KEY (dept_id);

    Question: Does index get created automatically because this is a PK?


    2. Index on foreign keys in the children tables to prevent deadlocks
    and lock escalations.

    CREATE INDEX fk_index ON employee_addres ses (emp_id)


    3. Indexes on common queries on all three tables.

    CREATE INDEX common_query_id x on employees(last_ name, first_name,
    position)


    CREATE INDEX common_query_id x on departments(las t_name, first_name,
    position)


    CREATE INDEX common_query_id x on employee_addres ses(street, city)


    Question: Given that the searches can be on any field separately and
    in any combination should I also put an index on each column
    individually or will the composite index take care of individual
    searches as well? For example, will the above indexes be sufficient
    for the following SELECT:

    SELECT e.last_name, e.first_name from employees e, departments d,
    employee_addres ses ea, dept_employees de WHERE e.emp_id = de.emp_id AND
    d.dept_id = de.dept_id AND ea.emp_id = e.emp_id AND e.position =
    'master chief' AND d.dept_name = 'galactic affairs' AND ea.city='Los
    Angeles'


    4. Unique index on the association table. Again this is accomplished
    using PK

    ALTER TABLE dept_employees ADD PRIMARY KEY (dept_id, emp_id)

    Question: Is the index on (dept_id, emp_id) automatic because of PK?

    5. The association table has to go both ways and PK takes care only of
    the first half. Thus add an index to go the other way.

    create unique index dept_employee_i dx on dept_employee(e mp_id,dept_id)

    Question: should I use INDEX ORGANIZED TABLE?

    Question: should I have UNIQUE qualifier on the second index given that
    PK already takes care of it?


    Thanks,

    Robert


    ===== EXAMPLE ======


    1) An employee can be in many departments and a department can contain
    many employees.

    2) Common searches for employees are on last_name, first_name,
    position, department_name , department_loca tion separately and in any
    combination.

    3) There are common searches for departments that contain certain
    employees e.g. find all departments containing John Smith.


    CREATE TABLE employees
    (
    emp_id INTEGER NOT NULL,
    last_name VARCHAR(50) NOT NULL,
    first_name VARCHAR(25) NOT NULL,
    position VARCHAR(10) NOT NULL
    );


    CREATE TABLE employee_addres ses
    (
    address_id INTEGER NOT NULL,
    emp_id INTEGER NOT NULL,
    street VARCHAR(50) NOT NULL,
    city VARCHAR(25) NOT NULL,
    );


    CREATE TABLE departments
    (
    dept_id INTEGER NOT NULL,
    dept_name VARCHAR(50) NOT NULL,
    dept_location VARCHAR(25) NOT NULL,
    );


    CREATE TABLE dept_employees
    (
    dept_id INTEGER NOT NULL,
    emp_id INTEGER NOT NULL,
    );

    ALTER TABLE employee_addres ses ADD FOREIGN KEY (emp_id) REFERENCES
    employees(emp_i d)

    ALTER TABLE dept_employees ADD FOREIGN KEY (emp_id) REFERENCES
    employees(emp_i d)

    ALTER TABLE dept_employees ADD FOREIGN KEY (dept_id) REFERENCES
    departments(dep t_id)

  • Erland Sommarskog

    #2
    Re: What are common indexes?

    (robertbrown197 1@yahoo.com) writes:[color=blue]
    > 1. Index on primary keys in all three tables. My understanding that
    > this indexing happens automatically just by declaring that a column is
    > a PK.
    >
    > ALTER TABLE employees ADD PRIMARY KEY (emp_id);
    > ALTER TABLE employee_addres ses ADD PRIMARY KEY (address_id);
    > ALTER TABLE departments ADD PRIMARY KEY (dept_id);
    >
    > Question: Does index get created automatically because this is a PK?[/color]

    Yes. That is how a PK is implemented. (As is a UNIQUE constraint.)
    By default a PK is clustered, but this does not mean that the PK
    is always the best choice for the clustered key. For an Employees
    table, for instance, the PK should probably be non-clustered.

    A good candidate for the clustered index might be last_name or dept_id
    (in the case an employee can belong to one department only).
    [color=blue]
    > 2. Index on foreign keys in the children tables to prevent deadlocks
    > and lock escalations.
    >
    > CREATE INDEX fk_index ON employee_addres ses (emp_id)[/color]

    Yes, this is a good idea. Notice that in some products this is
    created automatically. This is not the case in SQL Server. And with
    a good reason. Say that you have a Countries table, and your
    address table includes a country code. There is little reason to
    index addresses.count rycode, just because this is a FK reference,
    since Countries will be static, and you may never remove any rows
    from the table. (If you are search on country code it's another
    matter.)
    [color=blue]
    > 3. Indexes on common queries on all three tables.
    >
    > CREATE INDEX common_query_id x on employee_addres ses(street, city)
    >
    > Question: Given that the searches can be on any field separately and
    > in any combination should I also put an index on each column
    > individually or will the composite index take care of individual
    > searches as well? For example, will the above indexes be sufficient
    > for the following SELECT:
    >
    > SELECT e.last_name, e.first_name from employees e, departments d,
    > employee_addres ses ea, dept_employees de WHERE e.emp_id = de.emp_id AND
    > d.dept_id = de.dept_id AND ea.emp_id = e.emp_id AND e.position =
    > 'master chief' AND d.dept_name = 'galactic affairs' AND ea.city='Los
    > Angeles'[/color]

    The above index is not likely to be useful, because street is not
    included. It could still be used, because SQL Server could scan
    the index to find all entries. You would need an index with
    employee_addres ses.city as the first column.
    [color=blue]
    > 4. Unique index on the association table. Again this is accomplished
    > using PK
    >
    > ALTER TABLE dept_employees ADD PRIMARY KEY (dept_id, emp_id)
    >
    > Question: Is the index on (dept_id, emp_id) automatic because of PK?[/color]

    Yes.
    [color=blue]
    > 5. The association table has to go both ways and PK takes care only of
    > the first half. Thus add an index to go the other way.
    >
    > create unique index dept_employee_i dx on dept_employee(e mp_id,dept_id)[/color]

    Yes.
    [color=blue]
    > Question: should I use INDEX ORGANIZED TABLE?[/color]

    Eh? This is a term, I don't recognize.
    [color=blue]
    > Question: should I have UNIQUE qualifier on the second index given that
    > PK already takes care of it?[/color]

    Yes.


    --
    Erland Sommarskog, SQL Server MVP, esquel@sommarsk og.se

    Books Online for SQL Server SP3 at
    Get the flexibility you need to use integrated solutions, apps, and innovations in technology with your data, wherever it lives—in the cloud, on-premises, or at the edge.


    Comment

    • robertbrown1971@yahoo.com

      #3
      Re: What are common indexes?

      Erland Sommarskog wrote:
      [color=blue]
      >[color=green]
      > > 3. Indexes on common queries on all three tables.
      > >
      > > CREATE INDEX common_query_id x on employee_addres ses(street, city)
      > >
      > > Question: Given that the searches can be on any field separately and
      > > in any combination should I also put an index on each column
      > > individually or will the composite index take care of individual
      > > searches as well? For example, will the above indexes be sufficient
      > > for the following SELECT:
      > >
      > > SELECT e.last_name, e.first_name from employees e, departments d,
      > > employee_addres ses ea, dept_employees de WHERE e.emp_id = de.emp_id AND
      > > d.dept_id = de.dept_id AND ea.emp_id = e.emp_id AND e.position =
      > > 'master chief' AND d.dept_name = 'galactic affairs' AND ea.city='Los
      > > Angeles'[/color]
      >
      > The above index is not likely to be useful, because street is not
      > included. It could still be used, because SQL Server could scan
      > the index to find all entries. You would need an index with
      > employee_addres ses.city as the first column.[/color]

      Erland,

      So if I search for city separately and for street separately as well as
      together should I define two indexes on city and street individually as
      well as a composite index on both?

      [color=blue]
      >[color=green]
      > > 4. Unique index on the association table. Again this is accomplished
      > > using PK
      > >
      > > ALTER TABLE dept_employees ADD PRIMARY KEY (dept_id, emp_id)
      > >
      > > Question: Is the index on (dept_id, emp_id) automatic because of PK?[/color]
      >
      > Yes.
      >[color=green]
      > > 5. The association table has to go both ways and PK takes care only of
      > > the first half. Thus add an index to go the other way.
      > >
      > > create unique index dept_employee_i dx on dept_employee(e mp_id,dept_id)[/color]
      >
      > Yes.
      >[color=green]
      > > Question: should I use INDEX ORGANIZED TABLE?[/color]
      >
      > Eh? This is a term, I don't recognize.
      >[color=green]
      > > Question: should I have UNIQUE qualifier on the second index given that
      > > PK already takes care of it?[/color]
      >
      > Yes.
      >
      >
      > --
      > Erland Sommarskog, SQL Server MVP, esquel@sommarsk og.se
      >
      > Books Online for SQL Server SP3 at
      > http://www.microsoft.com/sql/techinf...2000/books.asp[/color]

      Comment

      • Erland Sommarskog

        #4
        Re: What are common indexes?

        (robertbrown197 1@yahoo.com) writes:[color=blue]
        > So if I search for city separately and for street separately as well as
        > together should I define two indexes on city and street individually as
        > well as a composite index on both?[/color]

        In the most extreme case you would need three indexes: (city), (street)
        and (city, street).

        But it depends a little on how selective the data is, the volumes etc.
        It could very well be sufficient with two indexes.

        I'll also like to add that search for street alone in address sounds a
        little funny to me, but I have the feeling that the examples your posted
        are not your real application, but posted for the question only.

        --
        Erland Sommarskog, SQL Server MVP, esquel@sommarsk og.se

        Books Online for SQL Server SP3 at
        Get the flexibility you need to use integrated solutions, apps, and innovations in technology with your data, wherever it lives—in the cloud, on-premises, or at the edge.


        Comment

        • AK

          #5
          Re: What are common indexes?

          >> Question: should I use INDEX ORGANIZED TABLE?
          <<

          SQL Server does not have them (Erland - IOTs are provided by Oracle),
          but a table with a clustered index is pretty much the same

          Comment

          • AK

            #6
            Re: What are common indexes?

            >> In the most extreme case you would need three indexes: (city), (street)
            and (city, street).
            <<

            Very interesting. Erland, please give an example when (street, city)
            and (city, street) would not suffice.

            Comment

            • Erland Sommarskog

              #7
              Re: What are common indexes?

              AK (AK_TIREDOFSPAM @hotmail.COM) writes:[color=blue][color=green][color=darkred]
              >>> In the most extreme case you would need three indexes: (city), (street)[/color][/color]
              > and (city, street).
              ><<
              >
              > Very interesting. Erland, please give an example when (street, city)
              > and (city, street) would not suffice.[/color]

              If all you want to search for is street, then city will be unnecessary
              baggage that will make the index unnecessarily big. Then again, that
              would mainly be an issue for queries like:

              SELECT street, COUNT(*) FROM tbl GROUP BY street

              --
              Erland Sommarskog, SQL Server MVP, esquel@sommarsk og.se

              Books Online for SQL Server SP3 at
              Get the flexibility you need to use integrated solutions, apps, and innovations in technology with your data, wherever it lives—in the cloud, on-premises, or at the edge.


              Comment

              • AK

                #8
                Re: What are common indexes?

                On one hand, I do agree to what you've just said.
                On the other hand, if there is a lot of OLTP activity against the
                table, I would *usually* have 2 bigger but reusable indexes on the
                table

                of course, there are exceptions - there are no hard and fast rules in
                our trade..

                Comment

                Working...