Сколько индексов нужно создать для более быстрых запросов - PullRequest
0 голосов
/ 20 сентября 2010

Моя объектная модель приведена ниже, и вы хотели бы, чтобы ваши входные данные по числу индексов создавались для более быстрых ответов на запросы (на h2, mysql).Допущения и вопросы приведены ниже для следующей модели.

@Entity
@Table(name = "user")
public class User  {

    @Id
    @GeneratedValue(strategy = IDENTITY)
    @Column(name = "id", unique = true, nullable = false, insertable = false, updatable = false)
    private Integer id;

    @ManyToOne(fetch = FetchType.LAZY)
    @ForeignKey(name = "fk_user_org_id")
    @Index(name = "idx_user_org_id")
    @JoinColumn(name = "org_id", nullable = false, referencedColumnName = "id")
    @NotNull
    private Organization organization;

    @ManyToOne(fetch = FetchType.LAZY)
    @ForeignKey(name = "fk_user_year_id")
    @Index(name = "idx_user_year_id")
    @JoinColumn(name = "year", nullable = false, referencedColumnName = "id")
    @NotNull
    private Year year;

    @ManyToOne(fetch = FetchType.LAZY)
    @ForeignKey(name = "fk_user_created_by")
    @Index(name = "idx_user_created_by")
    @JoinColumn(name = "created_by", nullable = false, referencedColumnName = "id")
    @NotNull
    private User createdBy;

    @Column(name = "name", nullable = false)
    private String name;

    @Column(name = "desc")
    private String desc;

    @Column(name = "is_system", length = LEN_1)
    @Type(type = "org.hibernate.type.YesNoType")
    private boolean isSystem = false;

    @Column(name = "user_type", nullable = false)
    private UserType userType;

    @Column(name = "status", nullable = false)
    @NotNull
    private Status status;

}

Наш план состоит в том, чтобы использовать многостолбцовые индексы вместо одного столбцового индекса (т. Е. Создать индекс user_idx на основе (организация, год, isSystem, состояние, userType), создано)).Предполагая, что у меня есть этот индекс, я получу оптимизированные ответы для моих запросов, перечисленных ниже.

  1. выберите * от пользователя, где организация = 1 и год = 2010;
  2. выберите * от пользователя, гдеорганизация = 1 и год = 2010 и isSytem = истина или ложь;(т. е. системные пользователи или пользователи, определенные в приложении)
  3. выберите * у пользователя, где организация = 1 и год = 2010, а isSytem = false и userType = Manager (то есть все менеджеры)
  4. select * от пользователягде организация = 1 и год = 2010, а isSytem = false и userType = сотрудник (т. е. все сотрудники)
  5. выберите * у пользователя, где организация = 1 и год = 2010, а isSytem = false и userType = Manager и status =ACTIVE (т. Е. Активные пользователи)
  6. выберите * у пользователя, где организация = 1 и год = 2010, а для createBy = 'Сэм' или 'Джо' [6] нужен другой многостолбцовый индекс, состоящий извышеупомянутые 3 столбца?

  7. Поскольку мы создаем многостолбцовый индекс согласно моему исходному предположению, могу ли я безопасно удалить отдельные индексы (idx_user_org_id, idx_user_year_id, idx_user_created_by), как определено в настоящее время вмодель?

1 Ответ

2 голосов
/ 20 сентября 2010

Вы должны изменить порядок столбцов в вашем индексе:

(organization, year, isSystem, userType, status, createdBy)

Это позволяет лучше обслуживать эти два запроса:

select * from user where organization=1 and year=2010 and isSystem=false and userType=Manager
select * from user where organization=1 and year=2010 and isSystem=false and userType=Employee

Нужен ли [6] другой многостолбцовый индекс, состоящий из трех вышеуказанных столбцов?

Ему не нужен новый индекс - он может использовать существующий, но менее эффективным образом - будут использоваться только первые два столбца. Добавление нового индекса для этого запроса выглядит хорошей идеей.

можно ли безопасно удалить отдельные индексы

Да. Вы должны удалить неиспользуемые индексы, в противном случае они просто займут дисковое пространство и замедлят изменения таблиц без какой-либо выгоды.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...